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Abstract 

In this paper, we present our proposal to Constraint Functional Logic Programming over 
Finite Domains (CFLP{TT>) ) with a lazy functional logic programming language which 
seamlessly embodies finite domain (TTT) constraints. This proposal increases the expres- 
siveness and power of constraint logic programming over finite domains (C LP(TT)) ) by 
combining functional and relational notation, curried expressions, higher-order functions, 
patterns, partial applications, non-determinism, lazy evaluation, logical variables, types, 
domain variables, constraint composition, and finite domain constraints. 

We describe the syntax of the language, its type discipline, and its declarative and opera- 
tional semantics. We also describe TO~y(J-T>), an implementation for CFLP(TT>) , and a 
comparison of our approach with respect to CLP(TT>) from a programming point of view, 
showing the new features we introduce. And, finally, we show a performance analysis which 
demonstrates that our implementation is competitive with respect to existing CLPiTTT) 
systems and that clearly outperforms the closer approach to CFLP{TV) . 

KEYWORDS: Constraint Logic Programming, Functional Logic Programming, Finite Do- 
mains. 



1 Introduction 

Constraint logic programming (CLP) ( Ja ffar and Maher 1994(1 was born from a 
desire to have both a better problem expression and performance than logic pro- 
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gramming (LP). Its success lies in that it combines the declarativeness of LP with 
the efficiency of the constraint programming (CP) paradigm. The essential com- 
ponent of the CLP schema is that it can be parameterized by a computational 
domain so that different domains determine different instances of the schema. Con- 
straint Programming over finite domains (CP(!FT>)) ( |Marriot and Stuckey 1998| 
IHenz and Miiller 2000(1 has emerged as one of the most exciting paradigms of pro- 
gramming in recent decades. There are several reasons for the interest that CP(TV) 

has raised: (1) the strong theoretical foundations ( |Tsang 1993||Apt 2003|IFriihwirth and Abdennadher 2 003) 
that make CP a sound programming paradigm; (2) CP(J-T>) is a heterogeneous 
field of research ranging from theoretical topics in mathematical logic to practical 
applications in industry (particularly, problems involving heterogeneous constraints 
and combinatorial search) and (3) CP is based on posing constraints, which are ba- 
sically true relations among domain variables. For this last reason, the declarative 
languages seem to be more appropriate than imperative languages to formulate TT> 
constraint problems. In particular, one of the most successful instances of CP(J-V) 
is CLP(TV) . 

Another well-known instance of declarative programming (DP) is functional pro- 
gramming (FP). The basic operations in functional languages are defined using 
functions which are invoked using function applications and put together using 
function composition. FP gives great flexibility, different from that provided by 
(C)LP, to the programmer, because functions are first-class citizens, that is, they 
can be used as any other object in the language (i.e., results, arguments, elements 
of data structures, etc). Functional languages provide evident advantages such as 
declarativeness, higher-order functions, polymorphism and lazy evaluation, among 
others. To increase the performance, one may think of integrating TT> constraints 
into FP (as already done in LP). However, literature lacks proposals in this sense 
and the reason seems to lie in the relational nature of J-T> constraints, which do 
not fit well in FP. In spite of this limitation, it seems clear that the integration of 
TT> constraints into FP is interesting not only for FP but also for discrete con- 
straint programming, as the constraint community may benefit from the multiple 
advantages of FP. 

More recently, functional logic programming (FLP) emerges with the aim to 
integrate the declarative advantages from both FP and LP. FLP gives rise to 
new features which cannot be found neither in FP nor in LP (Hanus 1994). FLP 
has not the inherent limitations of FP and thus it is an adequate framework 
for the integration of functions and constraints. To our best knowledge, the first 
proposal for a constraint functional logic programming scheme (CFLP) that at- 
tempts to combine constraint logic programming and functional logic programming 
is QDarlington et al. 1992| ). The idea behind this approach can be roughly described 
by the equation CFLP(V) = CLP(FP(V)), intended to mean that a CFLP lan- 
guage over the constraint domain T> is viewed as a CLP language over an extended 
constraint domain FP(T>) whose constraints include equations between expressions 
involving user defined functions, which will be solved via narrowing. Further, the 
CFLP scheme proposed by F.J. Lopez-Fraguas in QLopez-Fraguas 1992| ) tried to 
provide a declarative semantics such that CLP(T>) programs could be formally 
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understood as a particular case of CFLP(V) programs. In the classical approach 
to CLP semantics, a constraint domain is viewed as a first-order structure V, 
and constraints are viewed as first-order formulas that can be interpreted in V. 
In flLopez-Fraguas 1992) , CFLP{V) programs were built as sets of constrained 
rewriting rules. In order to support a lazy semantics for the user defined functions, 
constraint domains V were formalized as continuous structures, with a Scott domain 
l|Gunter and Scott 1990jl as a carrier, and a continuous interpretation of function 
and predicate symbols. The resulting semantics had many pleasant properties, but 
also some limitations. In particular, defined functions had to be first-order and de- 
terministic, and the use of patterns in function definitions had to be simulated by 
means of special constraints. 

In a recent work ( |L6pez-Fraguas et al. 2004a] ), a new generic scheme CFLP(T>) 
has been proposed, intended as a logical and semantic framework for lazy Constraint 
Functional Logic Programming over a parametrically given constraint domain V, 
which provides a clean and rigorous declarative semantics for CFLP{T>) languages 
as in the CLP(T>) scheme, overcoming the limitations of the older CFLP(V) 
scheme |L6pez-Fraguas 1992| ). CFLPiV) programs are presented as sets of con- 
strained rewriting rules that define the behavior of possibly higher-order and/or 
non-deterministic lazy functions over V. The main novelties in ( |L6pez-Fraguas et al. 20 04a) 
were a new formalization of constraint domains for CFLP , a new notion of interpre- 
tation for CFLP(T>) programs, and a new Constraint Rewriting Logic CRWLiV) 
parameterized by a constraint domain, which provides a logical characterization of 
program semantics. Further, flLopez-Fraguas et al. 2004b| ) has formalized an opera- 
tional semantics for the new generic scheme CFLPiV) proposed in ( |L6pez-Fraguas et al. 2004a| ). 
This work presented a constrained lazy narrowing calculus CLNC(V) for solv- 
ing goals for CFLP(V) programs, which was proved sound and strongly complete 
with respect to CRWL(T>ys semantics. These properties qualified CLNCiV) as 
a convenient computation mechanism for declarative constraint programming lan- 
guages. More recently, Ijdel Vado-Virseda 2005J) presented an optimization of the 
CLNC(T>) calculus by means of definitional trees ( |Antoy 1992| ) to efficiently control 
the computation. This new constrained demanded narrowing calculus CDNCiV) 
preserves the soundness and completeness properties of CLNC(V) and maintains 
the good properties shown for needed and demand-driven narrowing strategies 
dLoogen et al. 1993| |Antoy et al. 2000| Idel Vado-Virseda 2003jl . These properties 
adequately render CDNC(V) as a concrete specification for the implementation of 
the computational behavior in existing CFLPiV) systems such as TOy ( Caballe ro et al. 1997(1 
and Curry planus 1999|) . 

The main contributions of the paper are listed below: 

• The paper describes the theoretical foundations for the CFLP(TV) lan- 
guage, i.e., a concrete instance of the general scheme CFLP(T>) presented in 
flLopez-Fraguas et al. 2004a| |L6pez-Fraguas et al. 2004b| ). First, this instance 
includes an explicit treatment of a type system for constraints as well as for 
programs, goals and answers. Second, it also presents a new formalization of 
the constraint finite domain TV for CFLP that includes a succinct declara- 
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tive semantics (similarly as done for CLP) for an enough-expressive primitive 
constraints set. Finally, it provides the formal specification of a finite domain 
constraint solver defined over those primitive constraints that constitutes the 
theoretical basis for the implementation of correct propagation solvers. 

• The paper presents an operational semantics for finite domain constraint solv- 
ing on declarative languages using a new constraint lazy narrowing calculus 
CLNC(TV), consisting of a natural and novel combination of lazy evalua- 
tion and TV constraint solving that does not exist, to our knowledge, in any 
declarative constraint solver (see flLopez-Fraguas et al. 2004b| ) and Section^} • 
This operational semantics is defined with respect to a constraint rewriting 
logic over a TV setting that makes it very different from the operational 
behavior of CLP(TV) languages. 

• The paper presents TOy(TV) from a programming point of view, which is 
the first CFLP(TV) system that provides a wide set of TV constraints com- 
parable to existing CLP(TV) systems and which is competitive with them, 
as shown with performance results. Also, the advantages of combining TV 
constraints into FLP are highlighted via examples. Our system is therefore a 
contribution for increasing the expressiveness and efficiency of FLP by using 
TV constraints and a state-of-the-art propagation solver. 

The structure of the paper is as follows. Section [21 presents our CFLP(TV) 
language by describing its type discipline, patterns and expressions, finite domains, 
and constraint solvers. In Section|31 we provide a constraint lazy narrowing calculus 
over TV domains (CLNC(TV)) along with the notions of well-typed programs, 
admissible goals, and correct answers. Next, Section^Jdescribes our implementation 
of CFLP(TV): TOy(TV), highlighting the advantages obtained from embodying 
constraints into a functional logic language with respect to CLP(TV) , and compar- 
ing the performance of our CFLP(TV) system with other declarative constraint 
systems. Section [3] discusses related work and, finally, Section summarizes some 
conclusions and points out future work. 



2 The CFLP(TV) Language 

We propose a constraint functional logic programming language over finite domains 
which is a pure declarative language, typed, lazy, and higher-order, and that pro- 
vides support for constraint solving over finite domains. CFLP(TV) aims to the 
integration of the best features of existing functional and logic languages into TV 
constraint solving. 

In this section, we present the basis of our C FLP (TV) language about syntax, 
type discipline, and declarative semantics. We also formalize the notion of a con- 
straint finite domain and specify the expected behavior that a TV constraint solver 
attached to our CFLP(TV) language must hold. 
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2.1 Polymorphic Signatures 

We assume a countable set TVar of type variables a, (3, ... and a countable ranked 
alphabet TC = [JneN TCn of ^ e constructors C E TC n . Types r 6 Type have 
the syntax t ::= a \ C n . . . r„ | r — > r' | (n, . . . , r„). 

By convention, C t„ abbreviates C T\ . . . t„, "— >" associates to the right, ~T n — > r 
abbreviates n t„ — > r, and the set of type variables occurring in r is 

written tvar(r). A type r is called monomorphic iff tvar(r) — 0, and polymorphic 
otherwise, (ti, . . . ,r„) is a type intended to denote n-tuples. A type without any 
occurrence of "— ►" is called a datatype. Datatype definitions declare new (possibly 
polymorphic) constructed types and determine a set of data constructors for each 
type. Our CFLP{TT>) language provides predefined types such as [A] (the type of 
polymorphic lists, for which Prolog notation is used), bool (with constants true and 
false), int for integer numbers, char (with constants a, 6, . . . ) or success (with 
constant T). 

A polymorphic signature over TC is a triple £ = (TC, DC, FS), where DC — 
UneN -^C™ an d — UneN -f 1 ^ n are ranked sets of data constructors and evaluable 
function symbols. Evaluable functions can be further classified into domain depen- 
dent primitive functions PF n C FS n and user defined functions DF n = FS n \ 
PF n for each n G N. 

Each n-ary c £ DC™ comes with a principal type declaration c :: r„ — > C oik, 
where n,k > 0, a\, . . . , are pairwisc different, Tj are datatypes, and tvarfa) C 
{ai,. . . , afc} for all 1 < i < n. Also, every n-ary / € FS 1 ™ comes with a principal 
type declaration / :: t„ — > r, where Tj, r are arbitrary types. For any polymorphic 
signature S, we write £j_ for the result of extending DC in S with a special 
data constructor _L, intended to represent an undefined value that belongs to every 
type. We also assume that DC includes the three constants mentioned above 
true, false :: bool, and T :: success, which arc useful for representing the results 
returned by various primitive functions. As notational conventions, in the rest of 
the paper, we use c,d£ DC, f,g& FS and h <E DC U FS, and we define the arity 
of h G DC n U FS n as ar(h) = n. 

2.2 Expressions, Patterns and Substitutions 

In the sequel, we always assume a given polymorphic signature E, often not made 
explicit in the notation. We introduce the syntax of applicative expressions and 
patterns, which is needed for understanding the construction of constraint finite 
domains and constraint finite domain solvers. We assume a countably infinite set 
Var of (data) variables X, Y, . . . and the integer set Z of primitive elements 0, 1, 
— 1, 2, —2, . . . , mutually disjoint and disjoint from TVar and S. Primitive elements 
are intended to represent the finite domain specific set of integer values. 

An expression e G Exp±(Z) has the syntax e ::=_L| u | X \ h \ (ee') | 
(ei, . . . , e„) where u G Z, X G Var, h G DC U FS, (ee') stands for the application 
operation which applies the function denoted by e to the argument denoted by 
e' and (e\, . . . ,e n ) represents tuples with n components. The set of data variables 
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occurring in e is written var(e). Moreover, e is called linear iff every X 6 var{e) 
has a single occurrence in e, ground iff war(e) = and total iff is an expression 
with no occurrences of _L. Partial patterns t G Pat±(1 l ) C Exp_\_{1) are built as 
t ::= J_ | u | X | c<i . . . t m | ft\...t n where u G Z, X 6 Var, c G TJC with 
m < ar(c), and / G FS with n < ar(f). Notice that partial applications (i.e., 
application to less arguments than indicated by the arity) of c and / are allowed as 
patterns, which are then called higher-order patterns IjGonz alcz-Mor eno et al. 99b|l . 
because they have a functional type. We define the information ordering C as the 
least partial ordering over Pat±(Z) satisfying the following properties: 1 C i for 
all t G Pat±(Z) and h t m C h t' m whenever these two expressions are patterns and 
U E t'i for all i € {1, ... , m}. 

As usual, we define (data) substitutions a G Sub± (Z) as mappings a : Var — » 
Pat± (Z) extended to a : Exp± (Z) — > Exp± (Z) in the natural way. By convention, 
we write e for the identity substitution, ecr instead of cr(e) and o~9 for the composi- 
tion of a and 0. We define the domain dom(a) of a substitution a in the usual way. 
A substitution a such that o~a = a is called idempotent. For any set of variables 
A" C Var we define the restriction a \ X as the substitution er' such that dom(a') 
— X and cr'(AT) = cr(X) for all X G X. We use the notation a —x 9 to indicate 
that a \ X = 6 \ X , and we abbreviate a —\>ar\x as a =\v 6>. Tj/pe substitutions 
can be defined similarly, as mappings at : TVar — > Type with a unique extension 
<j t : Type — > Type, denoted also as ct*. The set of all type substitutions is denoted as 
TSubst. Most of the concepts and notations for data substitutions (such as domain, 
composition, etc.) make sense also for type substitutions, and we will freely use 
them when needed. 

2.3 Well-typed Expressions 

Inspired by Milner's type system IjDamas and Milner 1982|l we now introduce the 
notion of well-typed expression. We define a type environment as any set T of type 
assumptions X :: r for data variables s.t. T does not include two different assump- 
tions for the same variable. The domain dom(T) of a type environment is the set 
of all the data variables that occur in T. For any variable X G dom(T), the unique 
type t s.t. (X :: r) G T is denoted as T(X). The notation (h :: r) £ var S is 
used to indicate that S includes the type declaration h :: r up to a renaming of 
type variables. Type judgements (E, T) ^wt e :: r with e G Exp±(Z) are derived 
by means of the following type inference rules: 

(E, T) \~wt u :: int, for every u G Z. 
(E,T) h WT X :: r, if T(A) = r. 

(E,T) \-\vt h :: rcr t , if (h :: r) G l)a r Ej_, er t G TSubst. 

(E,T) h^T (e e') :: r, if (E,T) h WT e :: (r' -> r), (E, T) h WT e' :: r', 

for some r' G Type. 
(E,T) \- WT (ei,...,e n )::(ri,...,T„), if Vi G {1, . . . ,n} : (E,T) h^re,:^;. 

An expression e G Exp ^ is called well-typed iff there exist some type environment 
T and some type t, such that the type judgement (E, T) h^T e :: r can be derived. 
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Expressions that admit more than one type are called polymorphic. A well-typed 
expression always admits a so-called principal type (PT) that is more general than 
any other. A pattern whose PT determines the PTs of its subpatterns is called 
transparent. 

2-4 The Constraint Finite Domain TD 

Adopting the general approach of ( |L6pez-Fraguas et al. 2004a] |L6pez-Fraguas et al. 2004b| ), 
a constraint finite domain J-T> can be formalized as a structure with carrier set D%, 
consisting of ground patterns built from the symbols in a polymorphic signature E 
and the set of primitive elements Z. Symbols in £ are intended to represent data 
constructors (e.g., the list constructor), domain specific primitive functions (e.g., 
addition and multiplication over Z) satisfying monotonicity, antimonotonicity and 
radicality properties (see ( |L6pez-Fraguas et al. 2004a| for details), and user defined 
functions. Requiring primitives to be radical, which just means that for given ar- 
guments, they are expected to return a total result, unless the arguments bear too 
few information for returning any result different from _L. As we will see in the next 
subsection, it is also possible to instantiate this notion of constraint finite domain 
by adding a new formal specification of a constraint finite domain solver Solve^ 
as the theoretical basis of our operational semantics and implementation. 

Assuming then a constraint finite domain J-T>, we define first the syntax and 
semantics of constraints over TT> used in this work. In contrast to CLP[TV\ our 
constraints can include now occurrences of user defined functions and can return 
any value of the Type set. 

• Primitive constraints have the syntactic form pt n — At, being p G PF n a 
primitive function symbol and t\, . . . ,t n ,t G Pat±(7i) with t total. 

• Constraints have the syntactic form pe n — ►! t , with p G PF n , e\, . . . , e„ G 
Exp _l(Z) and t G Pat j_(Z) total. 

In the sequel, we use the notation PCon(J-V) for the set of all the primitive con- 
straints 7r over TT). We reserve the capital letter IT for sets of primitive constraints, 
often interpreted as conjunctions. The semantics of primitive constraints depends 
on the notion of valuation Val{TT>) over TT>, defined as the set of substitutions of 
ground patterns for variables. The set of solutions of tt G PCon(TV) is a subset 
Solyrjj^n) G Val{TT)) that satisfy 7r in TT> in the sense of ( |L6pez-Fraguas et al. 2004a| ). 
Analogously, the set of solutions of II G PCon(TT)) is defined as Sol^ v (n) = 
PItt^ n Soljr-p^n). Moreover, we define the set of solutions of a pair Una with 
a G Sub±(Z) as 5 , o^x>(n □ a) = Sol^viJ^) H Sol(a), where Sol (a) is the set of 
valuations r\ such that Xr] = trj for each X t G a . 

The next definition presents a possible specific polymorphic signature with fi- 
nite domain constraints constituted by a minimum set of primitive function sym- 
bols with their corresponding declarative semantics. By means of this signature, 
our CFLP(TT)) language allows the management of the usual finite domain con- 
straints defined over Z in CLP(TT)) and also equality and disequality constraints 



8 A.J. Fernandez, T. Hortald-Gonzdlez,F. S denz- Perez and R. del Vado-Virseda 
defined over Pat j_(Z) in a similar way as done in ijGo nzalcz-Morc no et al. 9 9b). 

Definition 1 

Consider the following usual primitive operators and relations defined over Z: 

Cg) z :: int — » int — > int, where® £ {+,—,*,/} 

x z :: int — > mt — > feoo^, where x e {=, ^, <,<,>, >}. 

Table 1. Primitive Function Symbols in .F2? and their Declarative Interpretation 



Strict Equality seq :: a —> a — > 6ooZ 
(on patterns) seq^ : D% x Z?z — > {true, false, _L} 

seg^ 23 ft-* trite, Vi G £>z total 

seq^ 13 t\ ta — > false, Vii,i2 G -Dz- ti,ia have no common upper 

bound w.r.t. the information ordering IZ 
seq^^ t\ t2 — » -L, otherwise 



Less or Equal ieg :: int — > int — > 6ooi 

(on integers) leq TT> : Dz x Dz — * {true, false, _L} 

leq TT> u\ ui — » true, if «i,«2 £ Z and lii < z U2 
leq FTI U\ U2 — » false, if u\,U2 £ Z and ui > z M2 
leq TT> u\ u-i — » _L, otherwise 



Operators 


® :: int — * int — » int 


(on integers) 






® TT> til H2^ Mi <g) Z M2 , if Ml , U 2 G Z 




(& TT> tii U2 _L, otherwise 


Finite Domains 


domain :: int — > [int] — * bool 




domain^ : Dz x Dz — ► {true, false, _L} 




domain^ u [ui, . . . , m„] — ► trMe, 




if Vi G {1, . . . ,n-l}.Mi < z M i+ i and 3i G {1, . . . ,n}.M = z Mi 




domain^ u [m, . . . , u n ) — * false, 




if 3i G {1, . . . ,n-l}.Ui > z Ui+i or Vi G {1, . . . ,n}.M / z m 4 




domain TT) u [mi, . . . , u n ] —+ _L, otherwise 


Variable Labeling 


indomain :: int — > success 




indomain^ : Dz —> {T, _L} 




indomain :FT ' u — » T, if m G Z 



indomain u — ► _L, otherwise 



Table ^ shows the set of primitive functions p S P_F™ with their corresponding 
type declarations and their declarative interpretation jr FT ' C £)g x considered 
in our constraint finite domain TT> (we use the notation p^tn — > i to indicate that 
(t n ,t) G p )■ We note that all our primitive functions satisfy the aforementioned 
properties. ♦ 
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The function indomain is the basis for a labeling (enumeration or search) strategy, 
which is crucial in constraint solving efficiency, labeling is applied when no more 
constraint propagation is possible, and its basic step consists of selecting a variable 
X with a non-empty, non-singleton domain, selecting a value u of this domain, 
and assigning « to X. We note that in our framework, various labeling strategies 
(variable and value selection) have all the same declarative semantics, but they may 
differ in their operational behavior and therefore in efficiency as it happens in the 
CLP (TV) setting (more details can be found in Section faAlJI . In the rest of the 
paper, when opportune, we use the following notations: 

• t == s abbreviates seq t s — A true and t \ — s abbreviates seq t s — A. false 
(the notations = and ^ can be understood as a particular case of the notations 
== and \ = when these are applied to integers and/or integer variables). 

• a < b abbreviates leq a b — A true (and analogously for the other comparison 
primitives <, > and >). 

• a <E) b >; c abbreviates o06^! r, r x c. 

• u € D abbreviates domain u D — A true and ui,...,u n E D abbreviates 
Mi G D A . . . A u n £ D. Analogously, u ^ D abbreviates domain u D — A false 
and u\, . . . ,u n £ D abbreviates Ui £ D A . . . A u n £ D. 

• domain [u\, . . . , u n ] a b with o, b £ 1 (a < b) abbreviates u\,...,u n £ [a .. b], 
where [a .. b] represents the integer list [a, a + 1, . . . , b — 1, b] that intuitively 
represents the integer interval [a,b]. 

• labeling L [u\, . . . ,u n ] abbreviates and extends indomain u± — >! T A ... A 
indomain u n — A T with a list L of predefined constants that allow to specify 
different labeling strategies. 

Using these notations, a primitive constraint store S C PCon(TT>) can be expressed 
as a finite conjunction of primitive constraints of the form t == s, t \ = s, u £ D, 
u ^ D, a ® b >; c, domain [u%, . . . , u n ] a b and/or labeling L [u%, . . . , u n ] where t, s 
are total patterns, Ui, u,a,b,c £ 7L U Var, and L, D are total patterns representing 
a variable or a list. 



2.5 Constraint Solvers over TT> 

The design of a suitable operational semantics over finite domains for goal solving 
in CFLP(TT>) combines constrained lazy narrowing with constraint solving over 
a given constraint finite domain TT>. The central notion of lazy narrowing can be 
found in the literature, e.g., ( |Middeldorp and Okui 1998| |Middeldorp et al. 2002| ). 
In this subsection, we describe the expected behavior of a constraint solver over the 
finite constraint domain TT> w.r.t. the semantics given in the previous subsection, 
as the basis of our goal solving mechanism. 

Definition 2 

A constraint solver over a given constraint domain TT> is a function named Solve^ 
expecting as parameters a finite primitive constraint store S C PCon(TT>) in the 
sense of Definition ^ and a finite set of variables \ ^= Var called the set of pro- 
tected variables. The constraint solver is expected to return a finite disjunction of 
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k alternatives: Solve :FT '(S,x) = Vi=i 0% acf i)i where each Si C PCon(TV) and 
each tTi 6 5u6j_(Z) is a total idempotent substitution satisfying the following re- 
quirements: no alternative can bind protected variables, for each alternative cither 
all the protected variables disappear or some protected variable becomes demanded 
(i.e., no solution can bind these variables to an undefined value), no solution is lost 
by the constraint solver, and the solution space associated to each alternative is in- 
cluded in one of the input constraint stores (i.e., SoIj^d(S) = Uj=i Solyr-p(Sinai)). 
In the case k = 0, the disjunction is understood as failure and Solyrv(S) = (that 
means failure detection). ♦ 

( |L6pez-Fraguas et al. 2004b"| ) describes a constraint solver defined on the domain 
Tiseq in which the constraints considered are just those for the strict (dis)equality 
on pure patterns (i.e. those patterns constructed over an empty set of primitive el- 
ements). Now, in this paper, we extend this solver to the constraint domain J-T> in 
which we consider Z as the set of primitive elements. We follow this approach and as- 
sume that the solver Solve :FV will behave as follows: Solve jrT> (S, x) — ViLit^i 1110 *) 
iff Sn e H-* ViLi^ 00 "*) t^x; where the relation W~ x expresses a solver resolution 
step, and Sue Vf- X indicates that S is in solved form w.r.t. the action of the con- 
straint solver in the sense of Definition [21 Moreover, the relation H~ x manipulates 
disjunctions by combining them as follows: 

... VSjDOi V ... H- x ... V \j }S,un : \ \l ... if S l aa l Vr x SJ^Sjaaj) 

Tables 12151 show the sets of rules that define the relation W~ x . These rules ex- 
tend and complement those presented in ( |L6pez-Fraguas et al. 2004b| ) specifically 
to work with finite domain constraints defined on the set of integer patterns. For 
clarity, we omit the corresponding failure rules, which can be easily deduced from 
our tables. 

Table |2] captures the operational behavior of the constraint solver Solve^ to 
manage constraints of the form seq, leq or domain when these return a variable 
as a result. The result variable is instantiated to each of its possible values (i.e., 
true and false) giving rise to different alternatives for each of the possibilities and 
propagating the corresponding bind to the remaining alternatives. 

Table 2. General Rules for the Constraint Solver 



seq t s R, S □ a H- x (t == s, SOi □ a0i) V {t \ = s, S6 2 □ a0 2 ) 

leq ab ->■! R, S a a H- x (a < b, S9i □ aOi) V (a > b, S6 2 □ a8 2 ) 

domain u [ui, ... ,u„] — >! 7?, S da W~ x (u £ [wi,... ,u n ], S6i □ a8i) V 

(u g [in,. . . ,u n ], S9 2 □ a9 2 ) 

(For the 3 rules) only if 71 ^ \; with Q\ = {R i— > true} and 9 2 = {R false} 
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Observe that, by applying the rules shown in Table |2 all the constraints based 
on the primitive seq are proposed as explicit constraints in form of strict equality 
or strict disequality. Then, the solver distinguishes several cases depending on the 
syntactic structure of the (integer) patterns used as arguments. Table [3] shows 
the rules to cover these cases that reproduce the process of syntactic unification 
between equalities and discqualities as it is done in the classical syntactic unification 
algorithms (see for example iFernandez 1992(1 '). 



Table 3. Rules for Strict (Dis)-Equality 



u == 


u, S □ 


a H- x 5" 


□ cr, if u € Z 






X == 


-t,Sn 


a H- x t - 


== t, S9 □ cr<9, if X i 


£ X U var(t), var(t) n x = % 


9 = {Ini} 


(h ti . 


..t n ) = 


= (ft si . 


. . Sn), S □ a W- X ti = 


= Si, . . . , tn == s n , Sn a 





u \ = u , S □ a Yr x S □ a, if u, u' g Z, and u t^ z u 

x\ = (hh. ..t n ), s □ a h- x (Vi(^i □ ^0) v (VLi(^ \ ^fe 61 . 5,61 1=1 ct61 )) 

if X £ x, var(h t\ . . .t„)n x ^ 9, Oi = {X >->■ hi Y mi }, with hi / h, and 
6 = {X 1— » U„}, Y mi , U n are new fresh variables. 
(h £1 . . .t n ) \ = u, S □ a H- x 5 □ a if u G Z 

(ft ii . . . t„) \ = (ft si . . . s n ), S a a H- x (ii \ = si, S □ a) V . . . V (t n \ = s n , S a a) 
(h t\ . . . t n ) \ = (h'si . . . s m ), S □ (7 H~ x S □ cr, if /i 7^ ft' or m 7^ n 



In addition to the rules for the strict (dis)equality over integer patterns, the solver 
has also to consider, by contrast to the solver given in ( |L6pez-Fraguas et al. 20 04b), 
new rules for the particular treatment of the primitive constraints (specific for TT>) 
defined over the primitive elements in 1. These rules are shown in Tabled 

Table 4. Rules for the Specific Primitive Constraints of TT> 



u < u' , S □ o H~ x S □ cr, if u, u' £ Z, and u < z u 
u > u , S □ a H- x S □ cr, if u,w' £ Z, and it > z u' 

a ® 6 x c, S □ cr H- x S □ a, if a, 6, c G Z and a ® z 6 x z c 

a®b = X, S U a\h x SO n a0, if X £ x, a,b £ Z and 6» = {X ^ a (g) Z b} 



Moreover, the solver also has to cover the domain and indomain classical con- 
straints in finite domain constraint programming languages, to respectively fix the 
domain of the constrained variables and label them according to their corresponding 
domain IjDechter 200 3 ). Table shows the new rules that consider these cases. 

After applying the constraint solver Solve J7 ' D , a primitive constraint store S C 
PCon(TT>) is expressed in solved form as a finite conjunction of primitive con- 
straints of the form (we use the notations given in Section l2~4l) X == t, X \ = t, 
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Table 5. Rules for Finite Domain and Variable Labeling 



it G [ui, . . 


. , U n ], S U a H~ x S U a, if u. 


tij 6 Z U Var and 3i 


e {l, . . . , n}. iti = u. 


u [ui, . . 


. , u n ], S U a H~ x S U a, if u. 


Ui € Z and Vi € {1, 


. . . , n}. Ui / z it. 


labeling [. 


..] [X], X G [«!,...,«„], S U 


a h- x vr=i( 5 '^ □ CT< 






if X (£x, and Vi 6 {1,..., 


n}, Ui £ Z and (9i = 


{X i— > it,} 


labeling [. 


. .] [it], S U a H- x S U er, if u 


g z 





u (z D and a®b^c where X £ Var, i is a total pattern, u,a,b,c G Z U Var and 
D is a total pattern defining a list of variables and/or integers. 

Example 1 

We illustrate the operational semantics of our finite domain constraint solver pro- 
viding a constraint solver derivation from the initial constraint store {seq X (s K) 
— >! R, A + B < Z} and taking into account the set of protected variables {Z}. 
We describe in detail the rules applied by the constraint solver and, at each goal 
transformation step, we underline which subgoal is selected: 

seq X (s K) ->! R. A + B < Z u e ^ {z} 

({X == s K, A + B < Z} u {R^ true}) V 
({X \ = s K, A + B < Z} u {R ^ false}) Yr {z} 

• ({ X == s K, A + B < Z} u {Rt-> true}) Vr {z} 

({ a K —— s K , A + B <Z} u {R i-> true, Ihs K}) Yr {z} 
{{K == K, A + B < Z} u {R h-> true, Ihs if}) ^{z} 
« ({ jf\_=_siC , A + B < Z} □ {i? i-> /aZse}) H~ m 

({A + B < Z} □ {i? /a^se, IkO})V 

({A + B < Z, M \ = K } □ {i? >-> J aZse, Xks M}) 

Therefore, the constraint solver returns the following solved forms: 

Solvent} seq X (s K) -»! R, A + B < Z }, {Z} ) = 

({A + B < Z, K == K} u {R H4 true, X h-> s if}) V 

({A + B < Z} u {R ^ false, X \-> 0}) V 

({A + B < Z, M \ = K} u {Rh4 / a Zse, X i-> s M}) 

As shown in Tables 2-5, our new constraint solver for the finite domain TD with 
strict equality and disequality has been designed to hold all the initial assumptions 
required in the general framework CFLP for constraint solvers (see Definition |2J . 
It can be formally proved by means of the following result. 

Theorem 1 

Let S C PCon(J-V) be a primitive constraint store, a G Sub j_(Z) an idempotent 
total substitution and x C Var a set of protected variables. If 5 □ a satisfies the re- 
quirements of Definition^ and Sua Yr x \l\ =1 {Si □ at), then SoIj?t>{S u a) — 
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Ui"=i Solyr-p^Si □ <7j), where dom(<Ji) (~l var(Si) — and x H (dom(<Ji) U rar^cr,)) 
= for all 1 < z < fc. Moreover, if S □ er ^ x fails then Soljr V (S a a) = 0. 

The proof of this theorem (see |Appcndix A| ) can be done distinguishing sev- 
eral cases from the declarative semantics of each primitive function symbol given 
in Table 1 and the requirements of each constraint solver rule in Tables 2-5. Ac- 
cording to this result, the relation H~ x preserves the requirements of a constraint 
solver and the constraint solver steps fail only in case of an unsatisfiable constraint 
store. Therefore, if we repeatedly apply this result from an initial constraint store 
and a set of protected variables in order to compute a constraint store in solved 
form, we directly obtain the correctness of our finite domain constraint solver w.r.t. 
CFLP{FVys semantics. 

3 The CLNC{FD) Calculus 

This section describes a lazy narrowing calculus with constraints defined on the 
finite domain TV (the Constraint Lazy Narrowing Calculus CLNC(J-"D) for short) 
for the solving of goals from programs. Since we have proved in the previous section 
that our finite domain constraint solver holds the properties required in the general 
framework, this calculus can be obtained as a simplified instantiation of the general 
scheme for CFLP described in | |L6pez-Fraguas et al. 2004b| ), and used in this work 
as the formal foundation of the operational semantics in TOy(J-V). 

In order to understand the main ideas of our operational semantics, we first give a 
precise definition for the class of well-typed programs, admissible goals and correct 
answers we are going to work with. 

3.1 Programs, Goals and Answers 

Our well-typed CFLP(J-T>) -programs are sets of constrained rewriting rules that 
define the behavior of possibly higher-order and/or non-deterministic lazy functions 
over J-T>, called program rules. More precisely, a program rule R for a defined 
function symbol / G DF n with an associated principal type t\ r n —* r 

has the form f t\ . . .t n = r <f= C and is required to satisfy the conditions listed 
below: 

1. t\ . . . t n is a linear sequence of transparent patterns and r G Exp±(1i) is a 
total expression. 

2. C is a finite set of total constraints (in the form of Definition [TJ, intended to 
be interpreted as conjunction, and possibly including occurrences of defined 
function symbols. 

3. There exists some type environment T with domain var(R) which well-types 
the defining rule in the following sense: 

(a) For 1 < i < n: (E, T) h WT U :: n . 

(b) (E, T) h WT r :: r. 

(c) For each (e == e') G C: 3fi G Type s.t. (E,T) \- WT e :: \i :: e'. 

(d) For each (e \ = e') G C: 3 t i G Type s.t. (E, T) \~ WT e :: /x :: e'. 
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(e) For each (it E D) E C: (E,T) h WT u " int,D :: [in*]. 

(f) For each (a^dxcjEC: (E, T) \~wt o, 6, c :: int 

where (E,T) e :: r :: e' denotes (E,T) H^t e :: r, (E, T) biyr e' :: r. 

The left-linearity condition required in item 1 is quite common in functional 
and functional logic programming. As in constraint logic programming, the condi- 
tional part of a program rule needs no explicit occurrences of existential quantifiers. 
Another distinguished feature of our language is that no confluence properties are 
required for the programs, and therefore functions can be non- deterministic, i.e. 
return several values for given (even ground) arguments. 

Example 2 

The following example illustrates the previous definition of typed CFLP(T'D)- 
programs by showing some constrained program rules which will be used for lazy 
evaluation of infinite lists in the next subsections. 



take :: int — > [a] — > [a] 
(Tl) take Xs 
(T2) take N [] 
(T3) take N [X \ Xs] 



[X\take (N - 1) Xs] 



N > 
N > 



checklist :: [int] — > int 
(CL1) check-list [] 
(CL2) check-list [X\Xs] 
(CL3) check-list [X\Xs] 
(CL4) check-list [X\Xs] 



= 

= 1 <= domain [X] 1 2 

= 2 <= domain [X] 3 4 

= 4 <= domain [X] 5 7 



generateFD :: int — > [int] 
(Gl) generateFD = [ ] 

(G2) generateFD N = [X | generateFD N] <= N > 0, domain [X] N-l 



from :: int — > [int] 
(F) from N =[N\ from (N+l)] 

According to ( |L6pez-Fraguas et al. 2004b| ), we define goals for this kind of pro- 
grams in the general form G = 3U. P □ C □ S u cr, where the symbol □ must be 
interpreted as conjunction, U is the finite set of so-called existential variables of the 
goal G, P is a multiset of so-called productions of the form e\ — > t±, . . . , e n — > t n , 
where e, E Exp± (TL) and ^ E Pai^ (Z) are totals for all 1 < i < n (the set of pro- 
duced variables of G is defined as the set of variables occurring in t\ . . . t n ), C is a 
finite conjunction of constraints (possibly including occurrences of defined function 
symbols), S is a finite conjunction of primitive constraints in the form of Defini- 
tion n called constraint store, and a is an idempotent substitution called answer 
substitution such that dom{o~) R var{P □ C □ S) = 0. 

Additionally, we say that a goal G is an admissible goal iff it is well-typed: satisfies 
the same admissibility criteria given above for programs for each constraint in C 
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and S, and the same conditions of compatible types for each production in P and 
each binding in a given in iGonzalcz-M oreno et al. 99b(l . Moreover, it must hold 
the so-called goal invariants given in ( |L6pez-Fraguas et al. 2004b| ): each produced 
variable is produced only once, all the produced variables must be existential, the 
transitive closure of the relation between produced variables must be irreflexive, 
and no produced variable enters the answer substitution. An admissible goal is 
called a solved goal iff P and C are empty and S is in solved form w.r.t. the action 
of the constraint solver in the sense of Definition [5] 

Similarly to IjGonz alcz-Mor eno et al. 99allGonzalez-Moreno et al. 99blldel Vado-Vi'rseda"2 003 ) , 
the CLNC(J-T>) calculus uses a notion of demanded variable to deal with lazy eval- 
uation. 

Definition 3 

Let G be an admissible goal. We say that X G var(G) is a demanded variable iff 

1. X is demanded by the constraint store S of G, i.e. [i(X) =/= _L holds for every 
jU € Soljr-p^S) (for practical use, the calculation of this kind of demanded 
variables in TT> can be easily done extending the rules given in the appendix 
of ( Lope zTYaguas et al. 2004b| ) in the line of our rules shown in Tables 2-5). 

2. X is demanded by a production (Xak — > t) € P such that, t (fc Var or k > 
and t is a demanded variable in G. 

Example 3 

We suppose an admissible goal with only the primitive constraint seq X (s K) 
— A R in the associated constraint store S. We note that K is not a demanded 
variable by S, because fx — {X i— > 0, K _L, R ^ false} £ SoIft>(S) (clearly, 
seq :FV n(X) (s K)n -> n(R) = false where n(X) = and (s K)n = s {n{K)) = 
s (_L) have no common upper bound w.r.t. the information ordering C, according 
to Table 1) but fi(K) — _L However, X and R are both demanded variables by 
S (according to the radicality property, any /j, £ Soljrx>{S) must satisfy /i(i?) total 
and then n(R) =/= _L and consequently fJ>(X) ^ _L). In this situation, if we have 
also a production F 1 — > X in the produced part of the goal involving a higher- 
order variable F, automatically F is also a demanded variable (by a production 
but not by the constraint store S). Moreover, we note that it is also possible to 
have a variable F demanded by both the constraint store (for example, if we add 
the primitive constraint F == © 2 to S) and a production (for example, F 1 — > 3 
instead of F 1 — > X). In this case, F is demanded twice, supplying more relevant 
and precise information for goal solving in the produced part and the constraint 
store of the goal. 

Finally, we describe the notion of correct answer that we want to compute from 
goals and programs in our CF LP (TUyir&mewoik. Since the calculus C LN C (TV) 
is semantically based on the Constraint ReWriting Calculus CRWL(J-T>), that 
represents a concrete instance over the constraint domain TT> of the constraint 
rewriting logic described in QLopez-Fraguas et al. 2004at , this logic can be also used 
as a logical characterization of our program semantics. On the basis of this logic, 
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we define our concept of correct answer with respect to an admissible goal G and 
a given CFLP(J r V)-program as a pair of the form II □ 8, where II C PCon(TV) 
and 9 E S*u6_l(Z) is an idempotent substitution such that dom(9) D var (II) = 0, 
fulfilling the same semantic conditions given in ( Lopez- Fraguas et al. 200 4b ) w.r.t. 
CRWL{V)'s semantics. 

The following example shows a correct answer for the admissible goal with only 
a strict equality □ take 3 (generateFD 10) == List □ □ and the CFLP(TT>)- 
program given in Example [21 

{X 1 ,X 2 ,X 3 E [0,1,2,3,4,5,6,7,8,9]} □ {List h- [X 1 ,X 2 ,X 3 ]} 

Analogously, it is also possible to prove that M E [1-.2] and M E [3. .4] (both of 
them with an empty substitution) are correct answers for the admissible goal with 
only a user defined finite domain constraint □ check Jist (from M) < 3 □ □. 
We will see in the next subsection how to compute all of these answers by means 
of the constrained lazy narrowing over TT>. 



3.2 Constrained Lazy Narrowing over TT> 

The calculus CLNC(TT>) can be obtained as a particular instantiation from the 
general CLNC(T>) calculus because we have proved that our finite domain con- 
straint solver satisfies the requirements given in the general framework. Therefore, 
the calculus CLNC(J-V) can be described as a set of transformation rules for ad- 
missible goals of the form GYr G' , specifying one of the possible ways of performing 
one step of goal solving. In this sense, derivations are sequences of H--steps where 
successful derivations will eventually end with a solved goal and failing derivations 
end with an inconsistent goal ■ We have two classes of goal transformation rules: 
rules for constrained lazy narrowing by means of productions, and rules for con- 
straint solving and failure detection. 

The goal transformation rules concerning productions are the same rules given 
in | |L6pez-Fraguas et al. 2004b| ) for general productions and are designed with the 
aim of modeling the behavior of constrained lazy narrowing with sharing, but now 
involving only the primitive functions over finite domains given in Definition ^ 
possibly higher-order defined functions and functional variables. 

The goal transformation rules concerning constraints can also be used to com- 
bine (primitive or used defined) finite domain constraints with the action of our 
constraint finite domain solver. As the main novelty, we note that only primitive 
constraints are sent to the TT> constraint solver. This is because non-primitive 
constraints are first translated to primitive ones by replacing the non-primitives 
arguments by new fresh variables before executing constraint solving and by regis- 
tering new productions between the non-primitive arguments and the new variables 
for lazy evaluation. Moreover, the constraint solver must protect all the produced 
variables of the goal in order to respect the constrained lazy evaluation and the 
admissibility conditions of goals. Additionally, the usual failure rules can also be 
used for failure detection in constraint solving and failure detection in the syntactic 
unification of the produced part of the goal. 
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Finally, we note that since Theorem 1 proves the correctness of our finite domain 
constraint solver w.r.t. the general framework, the main properties of the lazy nar- 
rowing calculus CLNC(J-T>), soundness and completeness w.r.t. the declarative se- 
mantics of C 'RW L(TT>) , follows directly from the general results of ( |L6pez-Fraguas et al. 2004b| ) . 
Obviously, these properties qualify CLNC(T'D) as a convenient computation mech- 
anism for constraint functional logic programming over finite domains and pro- 
vide a formal foundation for our CFLP(T'D) implementation TOy(J-V). From 
the viewpoint of efficiency, a computation strategy for CLNC(TT>) using defini- 
tion al trees flAntoy 1992|) has been proposed rec ently in Ijdel Vado-Virseda' 2005 ) 
and IjEstevez-Martin and del Vado-Virseda 2 005 ) for ensuring only needed narrow- 
ing steps and extend the efficient properties shown in QLoogen et al. 1993||Antoy et al. 2000 
Idel Vado-Virseda 2003JI guiding and avoiding don't know choices of constrained pro- 
gram rules over TV. 



3.3 Example of Goal Resolution by Using CLNC(J-'V) 

This section is closed with a simple example which illustrates the process of goal 
solving via the narrowing calculus CLNC(TV) and our finite domain constraint 
solver Solve™ '. We compute all the answers from the goal □ checklist (from M) 
< 3 n □ using the CFLP(J r T>)-progr&ms given in Example|21 Its resolution corre- 
sponds to the following sequence of goal transformation rules in ( |L6pez-Fraguas et al. 2 004b ) 
where, at each goal transformation step, we underline which subgoal is selected. 
indicates that the rule R in that work is applied. 



□ checklist (from M) < 3 o n e H~ac 

3X. checklist (from M) — ► X □ □ X < 3 □ e Vt-df 



At this point, we note that X is a variable demanded by the constraint store and 
we have several alternatives due to don't know choice of the program rule checklist: 

3X. checklist (from M) — ► X a □ X < 3 □ e H- DF ( C li) 

3X. from M -> [], -> X no X < 3 □ e H- SP{x ^o} 

from M -> [] □ □ < 3 □ s H- cs{0} (Solve™ ({0 < 3},0) = □ e) 

from M — ► [] □ □ □ e ^df(f) 

[M | from (M + 1)] -> [] □ □ □ s H^cf ■ 

The application of the first program rule for checklist leads to a failure derivation 
without answer. We apply now the second program rule of checklist: 

3X. checklist (from M) — »• X u □ X < 3 □ e H~df(cl2) 
3X',Xs',X. from M —> [X'\Xs'}, 1 -> X □ 

domain [X 1 ] 12nX<3ne H~sp{Xh^i} 
3X',Xs'. from M -» [X'\Xs'\ □ domain [X'\ 1 2 □ 1 < 3 □ e H- A c 
3X',Xs'. from M [X'\Xs'\ □ □ 1 < 3, domain [X 1 ] 1 2 □ e lf DF(F) 
3X',Xs'. [M | from, (M + 1)] -> [X'\Xs'\ □ □ 1< 3, domain [X'} 12 a e H- DC 
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3X', Xs'. M -> X\ from (M + 1) Xs' a O 

1 < 3, domain [X 1 ] 1 2 □ e ^sp{x'hM} 
3Xs'. from (M + 1) -> Xs' □ □ 1 < 3, domain [M] 1 2 □ e ^ EL 

□ □ 1 < 3, domain [M] 1 2 □ e H~cs(0) D □ M £ [1..2] □ e, because 
Solve™ {{I < domain [M] 1 2},0) = {M e [1..2]} □ e 

Therefore, we obtain the first computed answer IIi □ 0\ = {M G [1--2]} □ e. 
Analogously, we can apply the third program rule of checkjist: 

3X. checklist (from M) — > X □ □ X < 3 □ e H~d F ( CL 3) 

□ □ M E [3.. 4] □ e 

and we obtain the second computed answer II2 □ O2 = {M e [3. .4]} □ e. No more 
answers can be computed, because if we apply the fourth program rule of checklist 
we have again a failing derivation: 

3X. checklist (from M) —* X a □ X < 3 □ e H- DF ( CL 4) 

3X',Xs',X. from M [X'\Xs'}, 4 -> X a domain [X 1 ] 57 □ I < 3 □ £ 

^SP{X^4} 

3X',Xs'. from M -> [X'\Xs'} a domain [X') 5 7 □ 4 < 3 □ s H- AC 

AV. from M -> [X'\Xs'\ a □ 4 < 3, donlaTn [X 1 ] 5 7 □ e H- SF{X '.x s '} ■ 
because Solve^^A < 3, domain [X'\ 5 7},{X',Xs'}) = 

A detailed explanation of the computation of these answers using definitional 
trees in CLXC(TVi) to efficientl y guide and avoid don't know choices of cons trained 
program rules can be found in IjEstevez-Martin and del Vado-Virseda 2005(1 . More- 
over, we will see in the next section that these are exactly the same answers com- 
puted by our CFLP(TV) implementation TOy(TV). 

4 TOy(TV) 

So far, we have introduced the theoretical framework. Now, in this section we in- 
troduce TOy(J-"D), a CFLP(TV) implementation that extends the TOy system 
to deal with TT> constraints, highlight its advantages, and show its performance. 

4.1 Introducing TOy (TV) 

In this section, we describe TOy(TV) from a programming point of view, briefly 
describing its concrete syntax and some predefined TT> constraints. 

4.1.1 An Overview ofTOy(TV) 

TOy(J-'D) programs consist of datatypes, type alias, infix operator definitions, and 
rules for defining functions. The syntax is mostly borrowed from Haskell with the re- 
markable exception that variables and type variables begin with upper-case letters, 
whereas constructor symbols and type symbols begin with lower-case. In particular, 
functions are curried and the usual conventions about associativity of application 
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hold. As usual in functional programming, types are inferred, checked and, op- 
tionally, can be declared in the program. To illustrate the datatype definitions, we 
present the following examples using the concrete syntax of TOy : 

• data nat = zero | sue nat, to define the naturals, and 

• the Boolean predefined type as data bool = false | true; 

A TOy(J-V) program P is a set of defining rules for the function symbols 
in its signature. Defining rules for a function / have the syntactic basic form 
/ t\ ... t n = r <== C and, informally, its intended meaning is that a call to 
/ can be reduced to r whenever the actual parameters match the patterns ti, and 
the conditions in C are satisfied. TQy{TT)) also allows predicates (defined simi- 
larly as in logic programming) where predicates are viewed as a particular kind of 
functions, with type p :: ~f n — > bool. As a syntactic facility, we can use clauses as 
a shorthand for defining rules whose right-hand side is true. This allows to write 
Prolog-like predicate definitions, so that a clause p t% . . . t n : — C abbreviates 
a defining rule of the form p t\ ... t n = true <== C . With this sugaring in 
mind and some obvious changes (like currying elimination) it should be clear that 
(pure) CLP(!FT>) -programs can be straightforwardly translated to CFLP(J-T>)- 
programs. 

4-1-2 Simple Programming Examples 
Table|Hlshows introductory programming examples in TOy that do not make use of 

the extension over !FD, together with some goals and their outcomes ( |L6pez-Fraguas and Sanchez-Hernandez 1999| 

Note that infix constraint operators are allowed in TOy(J-T)) , such as // to 

build the expression X // Y, which is understood as // X Y. The goal (a) in 

the table sorts a list, in a pure functional computation. The answer for the goal (b) 

involves a syntactic disequality. In goal (c), F is a higher-order logic variable, and 

the obtained values for this variable are higher-order patterns (permut, sort,...). 

4.1.3 TV Constraints in TOy(TV) 

Table shows a small subset of the J-T> constraints supported by TOy(J-T>) , 
which are typical instances found in CP systems, and covers adequately the prim- 
itive constraints summarized in Tabic In Table int is a predefined type for 
integers, and [r] is the type 'list of t\ The datatype labelType is a predefined type 
which is used to define many search strategies for finite domain variable labeling 
IjFernandez et al. 20040 . 

Relational constraint operators are applied to integers and return a Boolean 
value. Arithmetical constraint operators are applied to and return integer values 
(the set of primitive elements). They can be combined with relational constraint 
operators to build (non)linear (dis)equations as constraints. Moreover, reified con- 
straints 1 can be implemented by equating a Boolean variable to a Boolean con- 
straint, for all of the constraints built from the operators in this table and the 

1 Reified constraints reflect the entailment of a constraint in a Boolean variable. In general, 
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Table 6. TOy Programming Basic Examples 



% Non-deterministic choice of one of two values 
infixr 40 // 
X // Y = X 
X // Y = Y 

% Non-deterministic insertion of an element into a list 
insert X [] = [X] 

insert X [Y|Ys] = [X,Y|Ys] // [Y I insert X Ys] 

% Non-deterministic generation of list permutations 
permut [] = [] 

permut [X|Xs] = insert X (permut Xs) 

% Testing whether a list of numbers is sorted 
sorted [] = true 
sorted [X] = true 

sorted [X,Y|Ys] = sorted [Y|Ys] <== X <= Y 

% Lazy l generate-and-test' permutation sort, 'check' calls 'sorted' which demands its 
% argument, which is lazily, non-deterministically generated by 'permut'. As soon as 
% the test fails, 'permut' stops the generation and tries another alternative 

sort Xs = check (permut Xs) 

check Xs = Xs <== sorted Xs == true 



Goal 




Answers 


(a) sort [4,2,5,1,3] == L 


L == [1,2,3,4,5] ; 


no more solutions 


(b) sort [3,2,1] /= L 


L /= [1,2,3] ; no 


more solutions 


(c) F [2,1,3] == [1,2,3] 


F == permut ; F == 


sort ; ... 



contraint domain (see Example 0J. Due to the functional component, we can apply 
this technique to equate Boolean expressions to Boolean constraints, as well. Both 
relational and arithmetical constraint operators are syntactically distinguished (by 
prefixing them with jf) from standard relational operators in order to denote its 
different operational behavior. Whereas a standard arithmetical operator demands 
its arguments, an arithmetical constraint does not. The membership constraint 
domain restricts a list of variables (its first argument) to have values in an integer 
interval (defined by its two next integer arguments) whenever its return value is 
true, whereas it restricts these variables to have values different from the interval 
when its return value is false. The enumeration constraint labeling assigns val- 
ues to the variables in its input integer list according to the options specified with 
the argument of type list of labelType. In this list, search strategies, such as first- 
constraints in reified form allow their fulfillment to be reflected back in an TT> variable. For 
example, X = (Y + Z > V) constrains X to true as soon as the disequation is known to be true 
and to false as soon as the disequation is known to be false. On the other hand, constraining X 
to true imposes the disequation, and constraining X to false imposes its negation. Usually, in 
C 'LP(T'D) languages, the Boolean values false and true directly correspond to the numerical 
values and 1, respectively. 
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Table 7. A Subset of Predefined TV Constraints in TOy{TV) 



RELATIONAL CONSTRAINT OPERATORS 

(#=). (#\=) :: int -> int -> bool 
(#<), (#<=). (#>). (#>=) int - int 
ARITHMETICAL CONSTRAINT OPERATORS 

(#+). (#-). (#*). (#/) :: int - int 
MEMBERSHIP CONSTRAINTS 

domain : : [int] — > int — > int — > bool 
ENUMERATION CONSTRAINTS 

labeling : : [labelType] — > [int] — » bool 
COMBINATORIAL CONSTRAINTS 

all_dif f erent : : [int] — > bool 



(Strict Equality) 
bool (Less or Equal) 

int (Operators) 

(Finite Domains) 

(Variable Labeling) 

(Global Constraints) 



fail (see Section 14. 5. Ill , as well as optimization options for finding minimum and 
maximum values for cost functions can be specified. The combinatorial constraint 
all.diff erent ensures different values for the elements in its list argument and 
is an example of the set of global constraints (for which an efficient propagation 
algorithm has been developed) supported by TOy(TV) . 

We do neither mention nor explain all the predefined constraints in detail and 
encourage the interested reader to visit the link proposed in ({Fernandez et al. 2004|) 
for a more detailed explanation. We emphasize that all the pieces of code in this 
paper are executable in TOy(TV) and the answers for example goals correspond 
to actual executions of the programs. 

4-1-4 Simple Examples with TV Constraints 

Example 4 

Below, we show the resolution at the TOy(TV) command line level of a simple 
goal that does not involve labeling. 

T0Y(FD)> domain [X, Y] 10 20, X #<= Y == L 

yes L == true, X in 10.. 20, Y in 10.. 20; 
yes L == false, X in 11.. 20, Y in 10.. 19; 
no 

Also note that this CFLP(TV) implementation only inform about a limited 
outcome, which consists of: (1) substitutions of the form Variable == Pattern, 
(2) disequality constraints Variable /= Pattern, (3) disjunctions D of constraints 
Variable in IntegerRange (these constraints denote the possible values a vari- 
able might take, as in common constraint systems; i.e., they do not state D, but 
negated D), and (4) success information: yes and no stand for success and failure, 
respectively. Finally, ' ; ' separates the solutions which has been explicitly requested 
by the user. Primitive constraints in the finite domain constraint store are not 
shown. 
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Example 5 

We show a TOy(TV) program involving labeling to solve the classical N-queens 
problem whose objective is to place N queens on an N x N chessboard so that 
there are no threatening queens. 

include "misc. toy" 
include "cflpfd.toy" 

queens : : int -> [labelType] -> [int] 

queens N Label = L <== length L == N, domain LIN, 

constrain_all L, labeling Label L 

constrain_all : : [int] -> bool 
constrain_all [] = true 

constrain_all [X|Xs] = true <== constrain_between X Xs 1, 

constrain_all Xs 

constrain_between : : int -> [int] -> int -> bool 
constrain_between X [] N = true 

constrain_between X [Y|Ys] N = true <== no_threat X Y N, 

constrain_between X Ys (N+l) 

no_threat : : int -> int -> int -> bool 

no_threat X Y I = true <== X #\= Y, X #+ I #\= Y, X #- I #\= Y 

The intended meaning of the functions should be clear from their names and def- 
initions, provided that length L returns the length of the list L. The first two lines 
are needed to include predefined functions such as length and domain. An example 
of solving at the command prompt, where f f stands for the first-fail enumeration 
strategy (see Section 14 1 5. 1[) . is 

T0Y(FD)> queens 15 [ff] == L 

yes L == [1,3,5,14,11,4,10,7,13,15,2,8,6,9,12] 

Example 6 

We present a TOy{TT>) program using syntactic sugaring for predicate-like func- 
tions that solves the well-known CLP{TT>) program Send+More—Money. 

smm : : int -> int -> int -> int -> int -> int -> int -> int 
-> [labelType] -> bool 

smm SENDMORY Label :- 

domain [S,E,N,D,M,0,R,Y] 9, S #> 0, M #> 0, 
all_different [S,E,N,D,M,0,R,Y] , add SENDMORY, 
labeling Label [S,E,N,D,M,0,R,Y] 

add : : int -> int -> int -> int -> int -> int -> int -> int -> bool 
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add SENDMORY :- 1000#*S #+ 100#*E #+ 10#*N #+ D 

#+ 1000#*M #+ 100#*0 #+ 10#*R #+ E 
#= 10000#*M #+ 1000#*0 #+ 100#*N #+ 10#*E #+ Y 

For our simple TOyiTTf) programs, some examples of goals and answers which 
can be computed by TOy(J-V) are shown in Table 03 

Table 8. Examples of Goal Solving 



Goal 



Answers 



domain [A,B] 1 (1+2), A#>B, 
all_different [A,B] , labeling [ ] [A,B] 



A==2,B==1; A==3,B==1; 
A==3,B==2; no more solutions 



domain [X,Y,Z] 1 10, 

2 #* X #+ 3 #* Y #+ 2 #< Z 



X in 1. .2,Y==1,Z in 8. .10; 
no more solutions 



domain [X,Y,Z] 1 5, X #> Y, 
2 #* Y #> Z #+ 4, X #>= Z 



X in 4. .5, Y in 3. .4, Z in 1. .3; 
no more solutions 



smm SENDMORY [] 



S==9 , E==5 , N==6 , D==7 , M==l , Q==0 , 
R==8 , Y==2 , T==true ; 
no more solutions 



queens 5 [] == [M,A,E,Y,B] , 
smm SENDMORY [] 



M==l , A==3 , E==5 , Y==2 , B==4 , S==9 , 

N==6,D==7,0==0,R==8; 

no more solutions 



4.2 CFLP(TV) vs. CLP(TV) 

It is commonly acknowledged that CLP{TV) is a successful declarative approach; 
hence, we discuss the advantages of CFLP{TV>) , focusing on the TOy{Tl5) im- 
plementation, with respect to CLP{TT>). This section explains why the addition 
of FP features enhances the CLP setting. When necessary, we illustrate different 
features of CFLP(TT>) by means of examples. Further programming examples in 
pure functional logic programming and CFLP(J"D) can be found, respectively, in 
HLopez-Fraguas and Sanchez-H ernandez 19991 ) an d l|Fernandez et al. 20 04 ). 



4.2.1 CFLP(TV) D CLP(TV) 

As already pointed out, besides other features, CFLP{TT>) provides the main 
characteristics of CLP(J r P), i.e., TT> constraint solving, non-determinism and re- 
lational form. Moreover, CFLP(TV) provides a sugaring syntax for LP predicates 
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and thus, as already commented, any pure CLP(J-"I?)-program can be straightfor- 
wardly translated into a CFLP(J r I?)-program. In this sense, CLP{TT>) may be 
considered as a strict subset of CFLP(TT>) with respect to problem formulation. 
As a direct consequence, our language is able to cope with a wide range of applica- 
tions (at least with all those applications that can be formulated with a CLP{TT>) 
language). We will not insist here on this matter, but prefer to concentrate on the 
extra capabilities of CFLP{!FT>) with respect to CLP(J-T>). 

4.2.2 CFLP{TV) \ CLP{TV) 

Due to its functional component, CFLP(J-T>) adds further expressiveness to 
CLP(J-T>) as allows the declaration of functions and their evaluation in the FP 
style. In the following, we enumerate and discuss other features not present (or 
unusual) in the CLP(TT>) paradigm. 

Types. Our language is strongly typed and thus involves all the well-known ad- 
vantages of a type checking process, enhancing program development and mainte- 
nance. Each TT> constraint has associated, like any function, a type declaration, 
which means that a wrong use can be straightforwardly detected in the typical type 
checking process. 

Functional Notation. It is well-known that functional notation reduces the num- 
ber of variables with respect to relational notation, and thus, CFLP(TT)) increases 
the expressiveness of CLP(J-V) as it combines relational and functional notation. 
For instance, in CLP {TV) the constraint conjunction N=2 , X 6 [1,10-N] cannot 
be expressed directly and must be written adding a third component, as N=2, Max 
is 10-N, domain([X] ,l,Max) that uses an extra variable. However, TOy{TV) 
expresses that constraint directly as N==2 , domain [X] 1 (10-N). 

Currying. Again, due to its functional component, TOy{TV) allows curried func- 
tions (and thus constraints); for instance, see the application of curried TV con- 
straint (3#<)/l in Example [7] later in this section. 

Higher-Order and Polymorphism. In TOy{TV) functions are first-class citi- 
zens, which means that a function (and thus an TV constraint) can appear in any 
place where data do. As a direct consequence, an TV constraint may appear as 
an argument (or even as a result) of another function or constraint. The functions 
managing other functions are called higher-order (HO) functions. Also, polymorphic 
arguments are allowed in CFLP{TV). 

Example 7 

A traditional example of a polymorphic HO function is 



map : : (A -> B) -> [A] -> [B] 
map F [] = [] 

map F [XlXs] = [(F X) I (map F Xs)] 
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that receives both a function F and a list as arguments and produces a list resulting 
from applying the function to each element in the list. Now, suppose that X and 
Y are TV variables ranging in the domain [0..100] (expressed, for instance, via the 
constraint domain [X,Y] 100). Then, the goal map (3#<) [X,Y] returns the 
Boolean list [true, true] resulting from evaluating the list [3#<X,3#<Y], and X 
and Y are also restricted to have values in the range [4,100] as the constraints 
3#<X and 3#<Y are sent to the constraint solver. Note also the use of the curried 
function (3#<). 

Laziness. In contrast to logic languages, functional languages support lazy evalu- 
ation, where function arguments are evaluated to the required extend (the call-by- 
value used in LP vs. the call-by-need used in FP). Strictly speaking, lazy evaluation 
may also correspond to the notion of only once evaluated in addition to only required 
extent UPeyton- Jones 1987| ). TOy{TV) increases the power of CLP (TV 1 ) by in- 
corporating a novel mechanism that combines lazy evaluation and TV constraint 
solving, in such a way that only the demanded constraints are sent to the solver. 
This is a powerful mechanism that opens new possibilities for TV constraint solving. 
For example, in contrast to CLP(TV), it is possible to manage infinite structures. 

Example 8 

Consider the recursive functions take and generateFD from Example [3 An ea- 
ger evaluation of the following goal does not terminate as it tries to completely 
evaluate the second argument, yielding to an infinite computation. However, a lazy 
evaluation generates just the first 3 elements of the list, as shown below: 

T0Y(FD)> take 3 (generateFD 10) == List 

yes List == [ _A, _B, _C ] _A, _B, _C in 0. .9 

In general, lazy narrowing avoids computations which are not demanded, there- 
fore saving computation time. ExamplelHlcontains a formulation of the typical magic 
series (or sequences) problem ( |Van Hentenryck 1989| ). This example highlights the 
expressive power of TOy(TV) by solving multiple problem instances that can be 
described and solved via lazy evaluation of infinite lists. 

Example 9 

LetS = (so, si, sjy_i) be a non-empty finite series of non-negative integers. 

The series S is said N-magic if and only if there are s^ occurrences of i in S, for 
all i G {0, . . . ,N-1}. Below, we propose a TOy(TV) program to calculate magic 
series where the function generateFD is as defined in Example [3 

lazymagic : : int -> [int] 

lazymagic N = L <== take N (generateFD N) == L, 

constrain L L Cs, sum L (#=) N, 
scalar_product Cs L (#=) N, labeling [ff] L 

constrain : : [int] -> [int] -> int -> [int] -> bool 
constrain [] A B [] = true 
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constrain [X|Xs] L I [J I Js] = true <== I==J, count I L (#=) X, 

constrain Xs L (1+1) Js 

sum/3, scalar .product /4 and count /4 are predefined HO constraints (Ferna ndez et al. 2004|l 
that accept a relational TT> constraint operator with type int — > int — * bool as 
argument (e.g., the constraint #=). sum L C N means that the summation of the 
elements in the list L is related through C with the integer N (in the example, the 
summation is constrained to be equal to N). scalar_product and count stand for 
scalar product and element counting under the same parameters as sum. 

A goal lazymagic N, for some natural N, returns the N-magic series where the 
condition take N (generateFD N) is evaluated lazily as (generateFD N) produces 
an infinite list. More interesting is to return a list of different solutions starting from 
N. This can be done using a recursive definition to produce the infinite list of magic 
series (from N) as shown below. 

magicfrom :: int -> [[int]] 

magicfrom N = [lazymagic N I magicfrom (N+l)] 

Now, it is easy to generate a list of magic series by lazy evaluation. For example, 
the following goal generates a 3-element list containing, respectively, the solution 
to the problems of 7-magic, 8-magic and 9-magic series. 

T0Y(FD)> take 3 (magicfrom 7) == L 

yes L == [[3,2,1,1,0,0,0], 

[ 4, 2, 1, 0, 1, 0, 0, ] , 

[ 5, 2, 1, 0, 0, 1, 0, 0, ] ] 

More expressiveness is shown by mixing curried functions, HO functions and func- 
tion composition (another nice feature from the functional component of TOy{J-T>)). 
For example, consider the TOy(J-'D) code shown below: 

from : : int -> [int] 
from N = [N I from (N+l)] 

(.):: (B -> C) -> (A -> B) -> (A -> C) 
(F . G) X = F (G X) 

lazyseries :: int -> [[int]] 
lazyseries = map lazymagic . from 

where ( . ) /2 defines the composition of functions. Observe that lazyseries curries the 
composition (map lazymagic) . from. Then, it is easy to generate the 3-element 
list shown above by just typing the goal 

T0Y(FD)> take 3 (lazyseries 7) == L 

This simple example gives an idea of the nice features of CFLP{TT>) that com- 
bines TT> constraint solving, management of infinite lists and lazy evaluation, cur- 
ried notation of functions, polymorphism, HO functions (and thus HO constraints), 
composition of functions and a number of other characteristics that increase the 
potentialities with respect to CLP{TV). 
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4-3 Correctness of the CFLP(FD) Implementation 

In this section, we briefly discuss the correctness of our TOy(TV) implementation 
with respect to our CFLP(TV) framework. 

TOy {TV) integrates, as a host language, the higher-order lazy functional logic 
language TOy ( |L6pez-Fraguas and Sanchez-Hernandez 1999| ) and, as constraint 
solver, the efficient TV constraint solver of SICStus Prolog (Carlss on et al. 1997(1 . 
Under the condition of considering just an empty set of protected variables, the SIC- 
Stus Prolog finite domain solver always satisfies the conditions for constraint solvers 
required in Section [2*31 Since the CLNC(TV) calculus is strongly complete (see 
( |L6pez-Fraguas et al. 2004b| )) in the sense that the choice of goal transformation 
rules can be a don't care choice, in practice, we can choose a suitable demand-driven 
strategy: our TV constraint solver is only applied at the end of the process of goal 
solving, when we have an empty set of protected variables (as we have done in the 
example in Section 3.3) or when protected variables are not relevant. This strategy 
can be performed in the CLNC(TV) calculus in the line of ( del Vado-Virscd a 2005?! 
as well as in TOy(TV) in the line of I Estevez-Martin and del Vado-Virseda 2 005 1 . 



Therefore, we can conclude that our operational semantics with this strategy covers 
adequately the TOy(TV) implementation. 

Additionally, we have run a number of tests in the implementation and have 
compared the derivations produced by the calculus C LN C (TV) to the traces ob- 
tained from debugging in TOy(TV), and the results show that these are effectively 
identical by following an adequate demand-driven strategy in C LN C (TV) . For in- 
stance, the CFLP(TV) program shown in Example [2 corresponds almost directly 
to a TOy (TV) program, and the solving of the goal checklist (from M) < 3 



in TOy (TV) is shown below (see IjEstevez-Martin and del Vado-Virseda 2005|> for 
more details). 



Toy(FD)> check_list (from M) < 3 
yes 

M in 1 . . 2 

Elapsed time: ms . 

more solutions (y/n/d) [y] ? 
yes 

M in 3 . . 4 

Elapsed time: ms . 

more solutions (y/n/d) [y] ? 
no . 

Elapsed time: ms . 



Note that the computed answers correspond exactly to those obtained in the goal 
solving process described in Section l3~""l via the narrowing calculus CLNC(TV). 
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4-4 Notes about the Implementation 



In TOy{TT>) : TT> constraints are evaluated internally by using mainly two pred- 
icates: hnf (E,H) , which specifies that H is one of the possible results of narrowing 
the expression E into head normal form, and solve/1, which checks the satisfia- 
bility of constraints (of rules and goals) before the evaluation of a given rule. This 
predicate is, basically, defined as follows 2 : 



(1) solve((<p, ip')) 

(2) solve(L == R) 

(3) solve(L / = R) 

(4) solve(L#0 R) 

(5) solve(C Ai . . . A n ) 



solve(ip) , solve(ip'). 
hnf (L, L' ) , hnf (R, R' ) , equal (L' , R' ) . 
hnf (L, L' ) , hnf (R, R' ) , not equal (L' , R' ) . 
hnf (L,L'),hnf (R,R'), {L'#<>R'}. 

where € {_ \=, <, <=, >, >=}. 
hnf (Ai, Ai), ■ • . ,hnf (A n , A n ), {C(Ai, . . . , A n )}. 

where C is any constraint returning a Boolean. 



The interaction with the constraint solver (i.e., SICStus TT> constraint solver in 
the current TOy(J-T>) version) is reflected in the last two clauses: every time an 
TT> constraint appears, the solver is eventually invoked with a goal {G} where G 
is the translation of the TT> constraint from TOy(J-T>) to SICStus Prolog. Head 
normal forms are required for constraint arguments in order to allow the solver to 
solve the constraint. 



4-5 Performance 

As far as we know, TOy{TT>) was the first FLP system integrating a TT> con- 
straint system. However, we know about the existence of an implementation of 
the FLP language Curry (Hanus 1999) that supports a limited set of TT> con- 
straints ( |Hanus M. (editor) 2005| ). This implementation, called PAKCS, provides 
the following constraints: 

(1) a set of arithmetical operations {*#,+#,-#,=#,/=#,<#,<=#,>#,>=#}, 

(2) a membership constraint domain /3, 

(3) some global constraints 3 and 

(4) an enumeration constraint labeling /l that also provides searching options. 
In this section, we compare the performance of TOy(J-T)) with that of the 

Curry2Prolog compiler, which is the most efficient implementation of Curry inside 
PAKCS (version 1.7.1 of December 2005). 

In addition, for evaluating if TOy(J-'D) is competitive with respect to existing 
CLP{TT>) systems, we have also considered four well-known CLP(TT>) systems: 

1. The version 3.12.1 of April 2005 of the TV constraint solver of SICStus Pro- 
log (jCarlsson et al. 1 9971 |SICStus Prolog 20051 ). This solver was included in 
order to measure the overhead due to the management of functional logic 



2 The code does not correspond exactly to the implementation, which is the result of many 
transformations and optimizations. 

3 Exactly, those named in this paper, i.e. all_dif f erent/1, count/4, scalar_product/4 and sum/3. 
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expressions, which are compiled to SICStus Prolog in TOy{TT>), and, there- 
fore, including all the stuff needed to handle the FLP characteristics such as 
laziness and higher-order functions. 

2. The GNU Prolog system (version 1.2.16) ( |Diaz and Codognet 2001) |GNU Prolog 2005| ), 
which is a free Prolog compiler that includes one of the most efficient finite 
domain constraint solver. This solver is based on the concept of indexicals 

Codognet and Diaz 1996| and it has been demonstrated that it has a per- 
formance comparable to commercial systems. 

3. SWI-Prolog (version 5.4.x) l|Wielemaker 20031 [5Wl-Prolog 20051 that it is an 
emergent and very promising Prolog system that provides an integer domain 
constraint solver implemented with attributed variables. 

4. Ciao Prolog (version 1.10#5 of August 2004) which is a full multi-paradigm 
programming environment for developing programs in the Prolog language 
and in several other languages which are extensions and modifications of 
Prolog in several interesting and useful directions. Ciao Prolog provides a 
package, based upon the indexical concept, to write and evaluate constraint 
programming expressions over finite domains in a Ciao program. 

4-5.1 Labeling 

Constraint solving can be implemented with a combination of two processes: con- 
straint propagation and labeling (i.e., search) IjDechter 2003(1 . The labeling process 
consists of (1) choosing a variable (variable ordering) and (2) assigning to the vari- 
able a value which belongs to its domain (value ordering). The variable ordering 
and the value ordering used for the labeling can considerably influence the efficiency 
of the constraint solving when only one solution to the problem is required. It has 
little effect when the search is for all solutions. In this study, we consider two label- 
ings, the naive labeling that chooses the leftmost variable of a list of variables and 
then selects the smallest value in its domain, and the first-fail labeling that uses 
a principle (Harali ck and Elliot 1980}) which says that to succeed, try first where 
you are the most likely to fail. This principle recommends the choice of the most 
constrained variable, which often means (for the finite domain) choosing a variable 
with the smallest domain. The naive labeling assures that both variable and value 
ordering are the same for all the systems and hence (although less efficient) is better 
for comparing the different systems when only one solution is required. 

4-5.2 The Benchmarks 

We have used a wide set of benchmarks 4 and, for the sake of fairness, whenever it 
was possible, we used exactly the same formulation of the problems for all systems 
as well as the same TT> constraints. The benchmarks used are: 

• cars: solve a car sequencing problem with 10 cars (Dincbas ct al. 1988). This 
benchmark deals with 100 Boolean variables (i.e., finite domain variables 

4 All the programs used in the comparison are available at http://www.lcc. uma.es/^afdez/cflpfd/ 
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ranging over [0,1]), 10 finite domain variables ranging over [1,6], 6 atmost 
constraints, 50 element constraints, and 49 linear disequations. 

• equation 10: a system of 10 linear equations with 7 variables ranging over 
[0,10]. 

• equation 20: a system of 20 linear equations with 7 variables ranging over 
[0,10]. 

• magic series (N): calculate a series of N numbers such that each of them is 

the number of occurrences in the series of its position in the series < |Codognet and Diaz 1 996 ) . 

• optimal Golomb ruler (N): find an ordered set of n distinct non-negative 
integers, called marks, a\ < ... < a n , such that all the differences dj — dj 
(i > j) are distinct and a n is minimum IjShearer 1990|l . 

• queens (N): place N queens on a N x TV chessboard such that no queen 
attacks each other | |Van Hentenryck~ 1989). 

• pythagoras: calculate the proportions of a triangle by using the Pythagorean 
theorem. This problem involves 3 variables ranging over [1,1000], and 7 dise- 
quality (non-linear) equations. 

• sendmore: a cryptoarithmethic problem with 8 variables ranging over [0,9], 
with one linear equation, 2 disequations and 28 inequality constraints (or 
alternatively one all-different constraint imposed over the whole set of con- 
strained variables). It consists of solving the equation SEND + MORE = 
MONEY. 

• suudoku: the problem is to fill partially filled 9x9 squares of 81 squares such 
that each row and column are permutations of [1,...,9], and each 3x3 square, 
where the leftmost column modulo 3 is 0, is a permutation of [1,...,9]. 

The programs equation 10, equation 20 and sendmore test the efficiency of 
the systems to solve linear equation problems. The programs cars and suudoku 
check the efficiency of specialized constraints such as the all-different constraint. 
The pythagoras problem deals with non-linear equations. 

The queens and magic series programs are scalable and therefore useful to test 
how the systems work for bigger instances of the same problem. Note that both 
the number of variables and the number of values for each variable grow linearly 
with the parameter N in the examples. That is, given a value N, at least N TV 
variables must be declared with domains that range between or 1 and N. 

The search for optimal Golomb rulers is an extremely difficult task as it 
is a combinatorial problem whose bounds grow geometrically with respect to the 
solution size i|Shearer 1990J) . This (also scalable) benchmark allows us to check the 
optimization capabilities of the system. 

4-5.3 Results 

All the benchmarks were performed on the same Linux machine (under Fedora Core 
system, 2.69-1667) with an Intel(R) Pentium 4 processor running at 2.40 GHz and 
with a RAM memory of 512 Mb. For the sake of brevity, we only provide the results 
for first solution search. 
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Table 9. TOy{TV) vs. C(F)LP Systems: Naive Labeling 
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Table 10. Speed-Up of TOy{TV) wrt. other C(F)LP Systems for Naive Labeling 



Benchmark PAKCS SICStus SWI GNU Ciao 
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1 00 
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0.20 
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Table shows the results using naive labeling. The meaning for the columns is 
as follows. The first column gives the name of the benchmark used in the com- 
parison, and the next six columns show the running (elapsed) time (measured in 
milliseconds) to find the first answer of the benchmark for each system. 

TablelTHlshows the results shown in TableElin terms of the speed-up of TOy{TV) 
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Table 11. TOy{TV) vs. C(F)LP systems: First-Fail Labeling 



Benchmark TOy(TV) PAKCS SICStus SWI GNU Ciao 
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with respect to the rest of the systems (that is, the result of dividing the time of a 
given system by the time of TOy(J-'D)). 

Table El shows the results of solving the same benchmarks by using first-fail 
labeling. Note that the current versions of SWI Prolog and Ciao Prolog do not 
provide first-fail labeling. Also, Table El shows the speed-up corresponding to the 
results in Table ITT1 and again displays the performance of TOy(J-V) with respect 
to the rest of the systems. The meaning for the columns is as in Table El but a 
last column is added in order to show the speed-up of TOy{J-T>) using first-fail 
labeling with respect to the same system with naive labeling. 

Tables El an d E] display corresponding results for optimization. Particularly, 
TablelT3lshows the (elapsed) time measured in milliseconds to solve the optimization 
problem considered in the benchmarking process, whereas Table lPTI shows the speed- 
up of our system with respect to the rest of the systems. 

In these tables, all numbers represent the average of ten runs. The symbol ?? 
means that we did not receive a solution for the benchmark in a reasonable time 
and (?) indicates a non-determined value. The symbol N in the PAKCS, SWI Prolog 
and Ciao Prolog columns mean that we could not formulate the benchmark because 
of insufficient provision for constraints. 

Also the notation OGS in the SWI column indicates that we received an error of 
Out Of Global Stack and, consequently, no answer was returned. In the GNU Prolog 
column, the notation (SO) number means that, in the first execution of the program 
no answer was calculated because a Stack Overflow error was raised, and that, after 
increasing significantly the corresponding (cstr and trail) environment variables, in 
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Table 12. Speed-Up of TOy{TV) wrt. other C(F)LP Systems for First-Fail La- 
beling 



Benchmark PAKCS SICStus SWI GNU Ciao TOy{TV) 
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Table 13. T Oy{TV) vs. C(F)LP Systems: Optimization Benchmarks 



Benchmark 


TOy {TV) 
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SWI 
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86 


N 
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5453220 
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N 
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N 



further executions we obtained an answer in the (average) time indicated by number. 
The notation RE in the SICStus Prolog column indicates that we also did not 
compute an answer because a Resource Error by Insufficient Memory was returned. 
The dash (-) in the Ciao Prolog column means that we received an incorrect answer 
for this benchmark 5 . 

As already declared, whenever possible we maintained the same formulation for 
all the benchmarks in each system. However, this was not always possible in the 
magic series benchmark. In the TOy{TT>), PAKCS and SICStus Prolog systems, 
this problem was coded by using specific constraints (i.e., count/4, sum/3 and 
scalar ^product /A - see formulation in Example|5J). However, the GNU Prolog system 



5 This event seems to be caused by a bug existing in the TT> constraint package. 



34 A.J. Fernandez, T. Hortald-Gonzdlez,F. Saenz-Perez and R. del Vado-Virseda 



Table 14. Speed-Up of TOy{TV) wrt. other C(F)LP Systems for Optimization 
Benchmarks 



Benchmark 


SICStus 
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SWI 


GNU 


Ciao 


golomb(8) 


0.77 


0.97 


oo 


0.23 


oo 


golomb(lO) 


0.98 


1.04 
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0.32 


oc 


golomb(12) 


0.98 


1.03 


oo 


0.40 
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lacks these constraints and, therefore, we used a classical formulation that requires 
to use reified constraints ( |Codognet and Diaz 1996| ). This classical formulation is 
somewhat different in TOy{TV) since reification applies to Boolean types (whilst 
in GNU Prolog, as in general in CLP {TV 1 ) languages, the Boolean values false and 
true correspond to the numerical values and 1 respectively). On the other hand, 
it was not possible in PAKCS as reified constraints are not available in this system. 
However, since SICStus Prolog allows reified constraints, the two formulations were 
considered in this system. Then, in the SICStus column and for the magic series 
benchmark row, we show between parentheses the (elapsed solving) time associated 
with the reified constraints-based formulation followed by the time associated to 
the alternative formulation based on the use of specific constraints. 

In the speed-up tables, in those cases in which for a particular system either a 
problem could not be expressed (e.g., for PAKCS, SWI Prolog or Ciao Prolog), or 
an error was returned avoiding to compute a first answer, or an incorrect answer 
was returned, we use the symbol oo to express that our system clearly outperforms 
that system since our system provides constraint support to formulate a solution 
for the benchmark and compute an answer. Also, a result > x. 00 indicates that 
TOy{J-V) computed an answer in 0.0 milliseconds and thus no speed-up can be 
calculated; in these 00 indicates that TOy{TV) is, at least, x times faster 

than the compared system. 

4-5.4 Analysis of the Results 

The third column in Tables ITU1 and ITSl and column 2 in Table IT~TI show that, in 
general, our implementation behaves closely to that of SICStus Prolog in both 
constraint satisfaction and constraint optimization (in fact, this is not surprising as 
current version of TOy{TV) uses SICStus Prolog TV solver) except for solving 
linear equations (in these cases it is between two and four times slower). The reason 
seems to be in the transformation process previous to the invocation of the TV 
solver. Expressions have to be transformed into head normal form, which means 
that their arguments are also transformed into head normal form (see Section l4.4[l . 
Thus, there seems to be an overhead when expressions (such as those for linear 
equations) involve a high number of arguments and sub-expressions. This may be 
the same reason argued to explain the slow-down of TOy{TV) in the solving of 
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the queens benchmark via first-fail labeling, although no appreciable slow-down was 
shown in the solving via naive labeling. 

PAKCS is between one and three times slower than our implementation. This 
is quite interesting as the PAKCS implementation is fairly efficient and is also 
based on the SICStus Prolog TV library. Perhaps the reason of this slowdown with 
respect to TOy(TV) is that PAKCS implements an alternative operational model 
that also supports concurrency, and this model introduces some kind of overhead 
in the solving of goals. 

TOy {TV) also performs reasonably well compared to the other CLP(TV) sys- 
tems. It clearly outperforms both Ciao Prolog's and SWI Prolog's constraint solvers 
which are far, in their current versions, from the efficiency of TOy(TV) in the solv- 
ing of constraint satisfaction problems (for fairness, we have to say that these results 
cannot be extrapolated to the whole Ciao Prolog and SWI Prolog systems which 
are quite efficient; in fact, the integer bounds constraint solver of SWI Prolog seems 
to be a rather non-optimized simple integer constraint solver that probably will be 
largely improved in future versions. This same argument can be applied to the finite 
domain constraint solving package currently existing in the Ciao Prolog system that 
seems to be non-mature yet). With respect to GNU Prolog's constraint solver, our 
system behaves acceptably well if we take into account that this solver has shown 
an efficiency comparable to commercial systems. Except for the N-queens bench- 
mark (that seems to be particularly optimized for GNU solver) our system is in 
the same order of efficiency. Moreover, it even behaves better on scalable problems 
when the size of the problem increases (e.g., in the magic series problem with naive 
labeling). In this sense, again with the exception of the N-queens problem, as the 
instance of the problem increases, the performance of TOy(TV) becomes closer 
to that of GNU Prolog (this result is confirmed for both constraint satisfaction and 
constraint optimization). 

Further, with regard to the comparison to the other CFLP(TV) system, we have 
to say that PAKCS provides a small set of global constraints (i.e., exactly four) as 
mentioned in Section PT5l whereas TOy(TV) also gives support to specialized con- 
straints for particular problems such as scheduling and placements problems. More- 
over, PAKCS does not provide TV constraints that help users to recover statistics 
of the constraint solving process (e.g., number of domain prunings, entailments de- 
tected by a constraint, backtracks due to inconsistencies, constraint resumptions, 
etc) which is very useful in practice, as TOy(TV) does. (For the sake of fairness, 
we mention again that PAKCS supports the concurrent evaluation of constraints 
which is also very convenient in practice.) 

Based on the results shown in this Section, we can assure that TOy(TV) is 
the first pure CFLP(TV) system that provides a wide set of TV constraints that 
makes it really competitive compared to existing CLP(TV) systems. These results 
encourage us to continue working on our approach, and we hope to further improve 
the results in a close future by means of introducing further optimizations. 
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5 Related Work 

In addition to already cited related work, in this section we discuss some more re- 
lated work. As already said, most of the work to integrate constraints in the declar- 
ative programming paradigm has been developed on LP ( |Codognet and Diaz 1996| 
ICarlsson et al. 1997|l . However, there exist some attempts to integrate constraints in 

the functional logic framework. For instance, IjArenas et al. 1996l|L6pez-Fraguas and Sanchez-Hernandez 1999| ) 

show how to integrate both linear constraints over real numbers and disequality 

constraints in the FLP language TOy. Also, IjLux 2001f) describes the addition of 

linear constraints over real numbers to the FLP language Curry planus 1999). Our 

work is guided to the TV constraint, instead of real constraints (although they are 

preserved) , which allows to use non- linear constraints and adapts better to a range 

of TV applications. 

With respect to TV, the closer proposal to ours is that described in ( |Antoy and Hanus" 2000) 
that indicated how the integration of TV constraints in FLP could be carried out. 
As already indicated, PAKCS is an implementation that follows these indications. 

TOy {TV) may also be considered from a multiparadigmatic view that means 
to combine constraint programming with another paradigms in one setting. In this 
context, there are some similarities with the language Oz ( |Van Roy et al. 2003| 
|Van Roy and Haridi 2004| ) as this provides salient features of FP such as composi- 
tional syntax and first-class functions, and features of LP and constraint program- 
ming including logic variables, constraints, and programmable search mechanisms. 
However, Ozis quite different to TOy(TV) because of a number or reasons: (1) 
Oz does not provide main features of classical functional languages such as ex- 
plicit types or curried notation; (2) functional notation is provided in Oz as a syn- 
tactic convenience; (3) The Oz computation mechanism is not based on rewriting 
logic as that of TOy(TV) ; (4) Oz supports a class of lazy functions based on a 
demand-driven computation but this is not an inherent feature of the language (as 
in TOy (TV) ) and functions have to be made lazy explicitly (e.g., via the concept 
of futures); (5) functions and constraints are not really integrated, that is to say, 
they do not have the same category as in TOy(TV) (i.e., constraints are func- 
tions) and both coexist in a concurrent setting, and (6) Oz programs follow a far 
less concise program syntax than TOy(TV). In fact, Oz generalizes the CLP and 
concurrent constraint programming paradigms to provide a very flexible approach 
to constraint programming very different to our proposal for CFLP(TV). 

Also, LIFE l)Ait-kaci and Podel ski 1993) is an experimental language aiming to 
integrate logic programming and functional programming but, as Oz, the proposal 
is quite different to TOy(TV) as firstly, it is considered in the framework of 
object-oriented programming, and, secondly, LIFE enables the computation over 
an order-sorted domain of feature trees by allowing the equality (i.e., unification) 
and entailment (i.e., matching) constraints over order-sorted feature terms. 

There exist other constraint systems that share some aspects with 
TOy(TV) although they are very different. One of those systems is FaCiLe 
IjBarnier and Brisset 20f)T)l . a constraint programming library that provides con- 
straint solving over integer finite domains, HO functions, type inference, strong 



Constraint Functional Logic Programming over Finite Domains 



37 



typing, and user-defined constraints. However, despite these similarities, FaCiLe is 
very different to TOy(TV) as it is built on top of the functional language OCaml 
that provides full imperative capabilities and does not have a logical component; 
also OCaml is a strict language, as opposed to lazy ones. In fact, as Oz , it allows 
the manipulation of potentially infinite data structures by explicit delayed expres- 
sions, but laziness is not an inherent characteristic of the resolution mechanism as in 
TOy (TV). Moreover, FaCiLe is a library and thus it lacks programming language 
features. 

Other interesting systems are OPL ( |Van Hentenryck 1999D and AMPL <|Fourer et al. 1 993 ) 
that cannot be compared to our work because they are algebraic languages which 
therefore are not general programming languages. Moreover, these languages do 
not benefit neither from complex terms and patterns nor from non-determinism as 
TOy{TV) does. 

Finally, we mention here another CFLP scheme proposed in the Phd Thesis 
of M. Marin IjMarin 2000jl . This approach introduces CFLP (V, S, £), a family of 
languages parameterized by a constraint domain V, a strategy S which defines the 
cooperation of several constraint solvers over V, and a constraint lazy narrowing cal- 
culus C for solving constraints involving functions defined by user given constrained 
rewriting rules. This approach relies on solid work on higher-order lazy narrow- 
ing calculi and has been implemented on top of Mathematica (M arin et al. 19991 
IMarin et al~2 000 l. Its main limitation from our viewpoint is the lack of declarative 
semantics. 

Generally speaking, TOy(TV) is, from its nature, different to all the constraints 
systems discussed above since TOy(TT>) is a pure FLP language that combines 
characteristics of pure LP and pure FP paradigms, and its operational mechanism is 
the result of combining the operational methods of logic languages (i.e., unification 
and resolution) and functional languages (i.e., rewriting). 



6 Conclusions and Future Work 

In this paper we have presented CFLP (TV), a functional logic programming ap- 
proach to TV constraint solving. CFLP(TV) is not only a declarative alternative 
to CLP(TV) but also extends its capabilities with new characteristics unusual or 
not existing in CLP(TV) such as functional and curried notation, types, curried 
and higher-order functions (e.g., higher-order constraints), constraint composition, 
higher-order patterns, lazy evaluation and polymorphism, among others. As a con- 
sequence, CFLP(TV) provides better tools, when compared to CLP (TV), for a 
productive declarative programming as it implicitly enables more expressivity, due 
to the combination of functional, relational and curried notation as well as type 
system. Moreover, lazy evaluation allows the use of structures hard to manage in 
CLP(TV), such as infinite lists. 

A CFLP(TV) language is also presented by describing its syntax, type discipline 
and both declarative and operational semantics. TV constraints are integrated as 
functions to make them first-class citizens and allow their use in any place where a 
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data can (e.g., as arguments of functions). This provides a powerful mechanism to 
define higher-order constraints. 

We have also reported an implementation of the CFLP(TV) proposal which 
connects a FLP language to a TV constraint solver, that provides both lazy com- 
putation and TV constraint solving. The TV solver is required to hold termination, 
soundness and completeness properties. TOy(TV) is our implementation of the 
CFLP(TV) language previously described, that connects the functional logic lan- 
guage TOy to the efficient TT> constraint solver of SICStus Prolog. The result is 
that TOy {TV) is a lazy functional logic system with support for TV constraint 
solving. 

We have also explained the most important contributions by showing the extra 
capabilities of CFLP(TV) with respect to CLP(TV) . This comparison points out 
the main benefits of integrating FLP and TV in a declarative language. 

Moreover, we have also shown that constraint solving in TOy(TV) is fairly 
efficient as, in general, behaves closely to SICStus Prolog, which means that the 
wrapping of SICStus Prolog by TOy does not increase significantly the computa- 
tion time. In addition, TOy(TV) clearly outperforms existing CLP(TV) systems 
such as SWI Prolog and Ciao Prolog and also is competitive with respect to GNU 
Prolog, one of the most efficient CLP(TV) systems. Furthermore, TOy(TV) is 
around one and three times faster than PAKCS, its closer CFLP(TV) implemen- 
tation. Practical applications of TOy(TV) can be found in IfFernandez et al. 20021 
IFernandez et al. 2003|l . 

Throughout the paper it should have been clear that one inherent advantage of 
the CFLP(TV) approach is that it enables to solve all the CLP(TV) applications 
as well as other problems closer to the functional setting. 

We claim that the integration of TV constraints into a FLP language receive 
benefits from both worlds, i.e., taking functions, higher-order patterns, partial ap- 
plications, non-determinism, lazy evaluation, logical variables, and types from FLP 
and domain variables, constraints, and propagators from the TV constraint pro- 
gramming. 

In addition, we claim that the idea of interfacing a FLP language and con- 
straint solvers can be extended to other kind of interesting constraint systems, such 
as non-linear constraints, constraints over sets, or Boolean constraints, to name a 
few. Observe that TOy(TV) can be thought of as a constraint solving procedure 
integrated into a sophisticated, state-of-the-art execution mechanism for lazy nar- 
rowing. Operationally speaking, TOy(TV) compiles CF-LP^X^-programs into 
Prolog-programs in a system equipped with a constraint solver. This makes both 
lazy evaluation and constraint solving be inherent features of the system. 
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Appendix A [Proof of Theorem 1] in Page 1121 

The proof of theorem 1 can be done distinguishing several cases from the declarative 
semantics of each primitive function symbol given in Table 1 and the requirements 
of each constraint solver rule or failure rule in Tables 2-5: 

Rules of Table 2 

We examine for example the first rule in Table 2: seq t s — >! R, S □ a H~ x 
(t == s, S6i □ cr0i) V (t \ = s, S9 2 □ a9 2 ) with R <£ x , °i = {R ^ tr ue\ 
and 9 2 = {R 1— > false} (the rest of rules in Table 2 are analogous). We prove that 
Solf-p^seq t s — ►! R, S □ a) = Solvit == s, S61 □ a9\) U Soljr V [t \ = s, S9 2 
□ o~9 2 ): 

C) Let r] £ Solyr-r>(seq t s — >! R, S □ a). By definition of Soljrj, we have 77 G 
Solj?v(seq t s — >! R) and 77 6 Sol^x>(S □ a). Since 77 € Sol^v{seq t s — >! R) we 
obtain seq^ tn srj — » rj{R) with rj(R) total. According to Table 1, r](R) must be 
only true or false. We distinguish two cases: 

• If rj{R) — true then trivially 77 € Soljr-p(seq t s — A true) or equivalently 
77 G Solj^T>{t == s). Moreover, since r](R) = true = (true)r) we have 77 G 
Sol (6\) and then #17/ = 77 (because 77(6*1 (i?)) = (truejrj — rj(R) and 77(6*1 (X)) 
= rj(X) for all X 7^ R). Then, since 77 G SoIft>{S □ er) we also have 6*177 G 
Soljr-p^S □ er), or equivalently 77 G SoI^-d{S9\ □ er6*i). We can conclude 77 G 
Solp%>(t —— s, S9i □ cr6*i). 

• If 77(7?) = false, using an analogous reasoning, we can also conclude 77 G 
Sol^(t \ = s, S9 2 □ a0 2 ). 

Therefore, 77 G Soljr V (t == s, S61 a a9 x ) U Soljr V (t \ = s, S9 2 a a9 2 ). 

D) Let 77 G Soljr V (t == s, 56*i □ a 61) U Solf V {t \ = s, S9 2 □ o9 2 ). We dis- 
tinguish again two cases: 

• If 77 G Sol^x>(t == s, S9i □ (t6*i) then, by definition of SoIj=t> we have 77 G 
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SolfT>(t == s) and r/ G So1^t>(S9i □ aOi) (or equivalently, 77 G Soljrx>(S0i) 
and 77 G Solyrj)(a9i)). Since 77 G SoIft>{o~9i) and i? ^ dom(a) (by initial 
hypothesis, sec/ < s — >! i?, 5 □ cr satisfy the requirements of Definition 2) 
we deduce 77 G Sol{9\) and then r?(i?) = (true)rj = true. But then, 77 G 
Sol^ v [seq t s —>\ R) because seq- FV tn sn — > 77 (i?) = true and we have 77 
G Soljrj){t == s). Moreover, 8ii] = 77 (because ri(9i(R)) = (true)ri — n(R) 
and r/(9i (X)) = n(X) for all X ^ R) and we can also obtain 77 G SoIftj(S 
□ cr) because 77 G SoIft>(S9i □ cr#i), or equivalently, #177 G Soljr V [S □ cr). 
Therefore, 77 G Sol^-r>(seq t s —>\ R, S n cr). 
• If ?7 G Solvit \ = s, S62 □ cr# 2 ), using an analogous reasoning, we can also 
conclude 77 G Sol^T>{seq t s — >! R, S □ cr). 

The remaining conditions of the theorem for this rule trivially hold because of the 
initial hypothesis seq t s — ►! R, S □ cr satisfies the requirements of Definition 2, 
and because of the conditions of the rule R £ \- 

Rules of Table 3 

We examine the first rule in Table 3: u —— w, S □ cr H~ x S a cr with u G Z. 
In this case, trivially Soljr V {u == u, S □ cr) = Soljrx,{u == u) n Soljr V (S □ cr) 
= Fa^JT?) n Soljr V (S □ cr) = SoIft>{S □ cr). The remaining conditions of the 
theorem trivially holds by initial hypothesis. We examine now the second rule in 
Table 3: X == t, S □ a W x t == t, S9 □ o9 with I^U var(t), var{t) n x = 
and 9 = {X ^ t}. We prove that SoIfd{X == t, S □ a) = Solvit == t, S9 

□ 0-6): 

C) Let 77 G SoIft>(X —— t, S □ cr). By definition of Sol^x* we have 77 G Sol^x>(X == 
t) and 77 G So1^t>(S □ cr). Since 77 G Solfv(X == t) we obtain seq^ r/(X) tn — > 
true. According to Table 1 we obtain n(X) = tn with £77 total and then 77 G Sol (6). 
In this situation, trivially 77 G Soljr V (t == t). Moreover, since 77 G Sol (6), we de- 
duce 9n = n (because n{6{X)) = tn = n{X) and n(0(Y)) = n(Y) for all Y ^ X). 
Then, since 77 G Sol^x>{S □ cr), we also have On G Sol^x>{S □ cr), or equivalently 
77 G Soljrx>{S9 □ crO). Therefore, we can conclude 77 G Soljr V {t == t, SO □ crO). 

2) Let 77 G Soljr V (t == t, SO □ a9). By definition of Soljr V we have 77 G 
Soljr-pft == t) and 77 G Soljr- D [S9 □ crO) (or equivalently, 77 G Solfv(SO) and 
77 G Soljr T ,(a9)). Since 77 G Sol?-p{o~9) and X £ dom(o~) (by initial hypothesis, 
X == t, S □ cr satisfies the requirements of Definition 2) we deduce 77 G Sol (6) 
and then n(X) = trj. But then, 77 G SoIj?d(X == t) because 77 G Solvit == t) and 
seq^ r](X) tn — ► trwe with n(X) = tn total. Moreover, On ^ n (because n{0{X)) 
= tn = n(X) and n(9(Y)) = n(Y) for all 7/1) and we can obtain 77 G Soljr V (S 

□ cr) because 77 G SoI?-d{S9 □ cr0), or equivalently, #77 G SoIft>{S □ cr). Therefore 
n G Solr V (X == t, S □ cr). 

The remaining conditions of the theorem for this rule trivially hold because of 
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the initial hypothesis X == t, S □ a satisfies the requirements of Definition 2, 
and because of the conditions of the rule I ^ U var(t) and var(t) n x = 0. 
Finally, we examine the main rule in Table 3 for strict discquality (the rest of rules 
in Table 3 are analogous or more simples): X \ = h t n , S □ a Vr x (\j ' ^SOi □ aOi)) 
V (Yk=i( U k \ = t k 0, S6 a <r6)) with X £ x , var(h ijnx / 0, 6 t = {X ^ h t 
Y mi ) with hi ^ h, and 9 = {X h U n } with Y mi , U n new fresh variables. We 
prove that Soljr V (X \ = h t n , S a a) = ( {J l Sol^ v (3Y mi . (S6, □ cr0;)) ) U ( 
ULi Sol„>{3U n . (U k \ - t h 6, S0 □ aO)) ): 

C) Let f] £ Soljr V (X \ = ht n , S □ a). By definition of Sol^x* we have 77 £ 
Soljr V (X \ = h t n ) and n £ Sol^r>{S □ a). Since r/ £ Soljr V (X \ = h t n ) we 
obtain seq^ 73 rj(X) (h t n )v —> false. According to Table 1, 77(A) and (h t n )r/ — 
h t n i] have no common upper bound w.r.t. the information ordering C, and we can 
distinguish two cases: 

• T](X) — hi s mi with hi ^ h. Since Y mi are new variables, we can define rf 
=yy V such that rj'(Y k ) = s k for all 1 < k < nii and r)'(Z) = n{Z) for all 

Z i Y m% . Clearly, n'(X) = n(X) = h t S m% = h t n'(Y mi ) = (h t Y mi )rf and 
then n' £ Sol(9i). Moreover, 6 if)' ~\y m V because w'(8i(Xj) = (hi Y mi )t]' 

= hi n'(Y mi ) = ht s mi = n(X) and rf(0i(Z)) = rf(Z) = n{Z) for all Z £ 
{X} U Y mi . Since n £ Sol^-p(S □ a) and Y mi are new variables in S □ a, 
we also have 0^' £ So1^t>{S □ a), or equivalently, n' £ Soljr V (S9i □ aOi). 
Finally, since there exists n' =\y m V wrt h Y mi new variables such that n' £ 

Solrv{S0i □ aOi) we can deduce r\ £ SoZjF£>(3Y~ mi . (S0i □ <7#,)) for any i 
such that hi ^ h. 

• 77(A) = h s n with a pattern s k (1 < k < n) such that Sk and t^r\ have no 
common upper bound w.r.t. the information ordering C (i.e., seq^ Sk t k n 
— > false). Since U n are new variables, we can define n' =\jj n n such that 
n'(U k ) = s k for all 1 < k < n a nd n'(Y) = 77(F) for all Y £ U n . Clearly, 
n'{X) = n(X) = hs n = h r}'(U n ) = (h U n )r}' an d then 7 / G S'oZ(6'). Moreover, 
^77' =\[j n V because n'(6(X)) = (h U n )t]' = h r]'(U n ) = h s n = n(X) and 
n'(8(Y)) = n'(Y) = n(Y) for all Y <£ {X} U U n . Therefore, there exists 1 < 
k < n such that seq- FV rj'(Uk) tkOr]' —> false because rj'(Uk) = s k and tkOn' 
= t k n (since U n are new variables, var(t k ) n U n = 0) and we can deduce n' 
£ Soljr V (Uk \ = t k 0). On the other hand, 77 G Soljr T) (S □ a), or equivalently 
On' £ SoIft>(S □ a), because U n are again new variables in S □ a. We can 
also conclude 77' G SoIft>{S0 □ a9). Finally, since there exists 77' V with 
U n new variables such that 77' G Sol^v{Uk \ = t k 0, SO □ a9), we obtain 77 G 
Soljr V (3Un. (U k \ = t k 9, SO □ aO)) (1 < k < n). 

2) Let 77 G ( U Soy v (3Y mi . (S6i □ 06$) ) U ( ULi S y v (3U n . (U k \ = t k 6, 
S8 □ a 6)) ). We distinguish again two cases: 

• 77 G Solfv(~3Y mi . (SOi □ <70i)) for any i such that hi 7^ /i. By definition of 
SoIfd, there exists 77' =>^ 77 such that 77' G Solj^x>(S6i □ cr^j) (or equiva- 
lently, 77' G Sol^v{S9i) and 77' G Sol^v{cr6i)). Since 77' G Soljr V ( a di) and X 



Constraint Functional Logic Programming over Finite Domains 



45 



^ dom{a) (by initial hypothesis, X \ = ht n , S □ a satisfies the requirements 
of Definition 2), we deduce 77' G Sol(9i) and then n'{X) — (hi Y mi )n' = 
hi v'O^mi)- Moreover, since 77' =\y m Vi we al so deduce 9 iff =\y m V because 
rf(6i{X)) = (hiT mi )r)' = rf{X) = n(X) and rf(6i{Z)) = rf{Z) = n{Z) for 
all Z £ {X} U Y mi . In this situation, seq F ' D rj'(X) (h t n )rj' — ► false, because 
r]'(X) — (hi Y mi )n' — hi 7]'(Y mi ) and (h t n )r]' = h t n r\' with hi ^ h have 
no common upper bound w.r.t. the information ordering C. Therefore, n' G 
Soljr- D (X \ = h t n ), and we also have 77 G SoIfd(X \ = h t n ) because Y mi 
arc new variables in X \ = h t n and n' =\y V- O n the other hand, since 
77' G Soljr- D (S9 i □ a6i), or equivalently 9it]' G SoI^-d(S □ a), and Y mi are 
new variables in S □ a, we obtain n G Soljr V (S □ a) because 9iv( =\y m V- 

Therefore, n G So1^t>(X \ = h t n , S □ a). 
• r\ G Sol rv (3U n . (U k \ = t k 9, S9 □ a6)) (1 < k < n). By definition of Sol rv , 
there exists n' =\jj n V such that rj G Soljr V (U k \ = t k 9, S8 □ ad) (1 < k 
< n). By definition of Soljrj, again we have rj G SolFv(U k \ = t k 9) and 77' 
G Soljr T> (S9 □ cr0) (or equivalently, 77' G Soljr V (S9) and 77' G Soljr V (a9)). 
Since 77' G Soljr V (a9) and X ^ dom(a) (by initial hypothesis, X \ = h t n , 
S a a satisfies the requirements of Definition 2) we deduce 77' G Sol(9) and 
then rj'(X) = (h U n )rj' = h rf (U n ). Moreover, since 77' 77, we also deduce 

<V =\ Fn r/ because t/(0(X)) = (/i ~U n )rj = n'(X) = r,(X) and rj (9(Z)) = 
rj(Z) = n(Z) for all Z £ {X} U U n . Since 77' G Solyr V (U k \ = t k 9), and 
according to Table 1, we have seq F ' D n'(U k ) t k 9rj — > /a^se where n'(U k ) 
and tfe^J?' = ifc?7 (because var(t k ) n £/„ = 0) have no common upper bound 
w.r.t. the information ordering C. In this situation, we also have seq F ' D r/(X) 
(h t n )rj — > /aZse because 7?(X) = (/i f7„)?7' = /i f]'(U n ), (h t n )r\ — h t n n, and 
clearly ?7(X) and (/i t n )r) have no common upper bound w.r.t. the information 
ordering C (there exists 1 < k < n such that rj(U k ) and ^77 have no common 
upper bound w.r.t. the information ordering C). Therefore, 77 G Soljrv(X \ = 
h t n ). On the other hand, since 77' G Soljr V (S0 □ cr9), or equivalently #77' G 
Soljr V (S □ (t), and £/„ are new variables in S □ a, we obtain 77 G SoIft>(S 
□ cr) because 9rj' = \jj V- Therefore, 77 G Sol^-u(X \ = ht n , S □ a). 

The remaining conditions of the theorem for this rule trivially hold because of the 
initial hypothesis X \ = ht n , S □ a satisfies the requirements of Definition 2, and 
because of the conditions of the rule X £ \, var(h t n ) fl x 0: an( i Y mi , U n are 
new fresh variables. 

Rules of Table 4 

We examine the first rule in Table 4: u < u', S □ a Vr x S □ a with u, v! G Z 
and 7t < z 7t'. In this case, trivially Sol^x>(u < u' , S n a) — Soljr V (u < u') (~l 
Soljr V (S □ cr) = Val(TV) n Soljr V (S u a) = Soljr V (S □ cr). The remaining 
conditions of the theorem trivially hold by the initial hypothesis. We examine now 
the main rule in Table 4 (the rest of rules arc analogous or more simples): a Cg) b = 
X, S □ cr Yr x S9 □ o9 with I^x, a,66Zand« = {I^s® z b}. We prove 
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that Sol^ v (a <8> b = A, S □ a) = Sol^ v (S9 □ crff): 

C) Let ?7 E Soljrx>(a ® 6 = X, 5 □ cr). By definition of Sol^x* we have 77 E 
Sol^j)(a ® b = X) and 77 E Soljr V (S □ cr). Since 77 £ SolfT,(a <g> 6 = X) we obtain 
(g)-^ 13 a 6 — > a (g) z 6, seg^ (a ® z 6) 77(A) — > true where a, b, a <g> z b £ Z. According 
to Table 1, we obtain 77(A) = a <g> z 6 = (a <g) Z 6)77 and then 77 £ Sol (6). Moreover, 
we deduce 6*77 = 77 because rj{9(X)) = (a <g> z 6)77 = a <X> Z b = 77(A) and rj{9(Y)) = 
77(F) for all y ^ X. Since 77 £ Sol^v{S □ cr) we also have #77 £ Soljr V {S □ cr), or 
equivalently, 77 £ SoIft>(S6 □ <t0). 

D) Let 77 £ Solrx>(S9 □ (70). By definition of Sol^x> we have 77 £ SoIft>(S6) 
and 77 £ SoIft>(&9)- Since by initial hypothesis a ® 6 = A, 5 □ cr satisfies the 
requirements of Definition 2, we have A ^ dom(a) and then 77 £ Sol (6) (i.e., 77(A) 
= (a ® z b)i] = (a ® z 6) £ Z, where a, 6 E Z). But then a b -> a <8> z 6, sec/^ 15 
(a <g> z 6) 77(A) — ► rjrue, and therefore 77 £ Solj:T>{a ® b = A). Moreover, #77 = 77 
because r?(0(A)) = (a ® z 6)7/ = a ® z b = 77(A) and n(9(Y)) = 77(F) for all Y ^ 
X. Since 77 £ Soljr V {S9 □ <t0), or equivalently 9r\ £ Sol^x>{S □ cr), we obtain 77 £ 
SoIft>(S □ cr). Therefore, 77 £ Sol^v{a ® 6 = A, 5 □ cr). 

The remaining conditions of the theorem for this rule trivially hold because of 
the initial hypothesis a <2) b = X, Sua satisfies the requirements of Definition 2, 
and because of the conditions of the rule A ^ \- 

Rules of Table 5 

We examine the first rule in Table 5: u £ [u\, . . . , u n ], S □ cr W~ x Sua with 
u, Ui £ Z U Vhr and 3i £ {1, . . . , n}. Ui = u. In this situation, and according to 
Table 1, we have Sol^v{u £ [ui, . . . , u n ]) = Val(TV): 77 £ Soljr V (u £ [u\, . . . , 
u n ]) implies that domain^ un [uin, . . . , u n rj\ —* true where Vi £ {1, . . . , n— 1}. 
Uj77 < z 7i i+ i?7 and 3i £ {1, . . . , n}. U77 = z 7^77. It holds for all 77 £ Val{TT>) be- 
cause of the initial hypothesis u £ [ui, . . . , w n ], Sua satisfies the requirements of 
Definition 2 (i.e., [u\, . . . , u n ] represents an increasing integer list), and because of 
the conditions of this rule (i.e., 3i £ {1, . . . , n}. Ui = u). Then, trivially SoI^-d{u 
£ [ui, . . . , u n ], S □ cr) = Soljrx>{u £ [ui, • • • , u n )) (~1 SoIft>(S □ cr) = Val{TT>) fl 
SoIft>{S □ cr) = SoIft>(S □ cr). The remaining conditions of the theorem for this 
rule trivially hold by the initial hypothesis. The second rule in Table 5 is completely 
analogous: SoI^-d{u £ [ui, . . . , tt n ]) = Val(T'D) because u, Ui £ Z, Vi £ {1, . . . , n}. 
Ui ^ z u, and according to Table 1, domain^ un [u\T], . . . , u„?7] — > /aZse holds for 
all 7/ £ yaZ(JRD). 

Finally, we examine the main rule for labeling in Table 5: labeling [. . .] [A], A 
£ [tii, • • • , tin], S □ cr ^ x V"=l D wrtn X x, an d Vt £ {1, . . . ,n}, tij 

£ Z, 0, = {A 1 ► tii}. We prove that Sol ^{labeling [. . .] [A], A £ [tii, . . . , ti„], S 
□ ^) = Ur=i SolrviSOi □ cr^): 
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C) Let 77 G Sol ^(labeling [. . .] [X], X G [wi, u n ], S □ cr). By definition 
of Solm we have 77 G Sol ^(labeling [. . .] [X], le [ui, . . . , u„]) and 77 £ Sol^x>{S 

□ cr). Then, indomain^ n(X) — > T, domain^ rj{X) [m, . . . , u n ] — > true because 
iti € Z for all 1 < 2 < 77. According to Table 1, we deduce ?7(X) e Z, Vi € {1, 
Ti—l}. Tij < z u i+ i and Eli G {1, ... , 77}. 77(X) — z m. Therefore, ?7(X) = m = UiV and 
then 77 G Sol(9i) (1 < i < n). Moreover, we have ^77 = 77 because n(9i(X)) = Uin = 
Ui = n(X) and ?7(0j(F)) = 77(F) for all Y ^ X. Finally, since 77 G So1^t>(S □ cr) we 
can conclude 6^77 G Soljr V (S □ cr) or equivalently 77 G Soljr- D (S9 i □ cr^) (1 < 7 < 77). 

D) Let 77 G Soljr V (S9i □ cr^) (1 < 7 < 71). By definition of Soljrj) we have 77 
G SolfT>(S6i) and 77 G Soljr^^crOi). By the initial hypothesis labeling [. . .] [X], X G 
[ui, . . . , u n ], 5* □ cr satisfies the requirements of Definition 2, we have X ^ dom(a) 
and then 77 G Sol(9i) (i.e., ?7(X) = 7^77 = due to ui G Z). Moreover, we have 
^77 = 77 because n(9i(X)) = Uin = m = n(X) and rj{9i{Y)) = 77(F) for all F ^ 
X. Then, since 77 G Soljrx>(S9i □ o~9i), or equivalently, 6^77 G Solfv(S □ cr), we 
deduce 77 G Sol^x>{S □ cr). Finally, we prove that 77 G Sol ^(labeling [. . .] [X], X 
G [tii, . . . , u n \). Since 7?(X), G Z for all 1 < i < n, [m, . . . , 77„] is an increasing 
integer list by the initial hypothesis, and there exists 1 < i < n such that n(X) = 
Ui G Z, according to Table 1 we can deduce domain^ r](X) [ui, . . . , u n ] — > true. 
Moreover, since ?7(X) G Z, trivially indomain :FT ' n(X) — ► T according again to 
Table 1. Then, indomain^ n(X) — ► T, domain^ n(X) [m, . . . , u„] — ► irTje, and 
we can conclude that 77 G Solf V (labeling [. . .] [X], X G [tii, . . . , 7i„]). Therefore, 
7/ G Soljr V (labeling [. . .} [X], X G [wi, ... , u n ], S □ cr). 

The remaining conditions of the theorem for this rule trivially hold because of 
the initial hypothesis labeling [. . .] [X], X G [ui, . . . , u n ], S □ cr satisfies the re- 
quirements of Definition 2, and because of the conditions of the rule X ^ The 
last rule for labeling follows a trivial reasoning because Sol^x>{labeling [. . .] [u]) = 
Val(J-T>) if 7i G Z. According to Table 1, indomain- FT> un — > T for all 77 G Val(J-T>). 
Therefore, Sol ^{labeling [. . .} [u], S □ cr) = Sol ^{labeling [. . .] [77]) n Sol^-p(S 

□ cr) = Val(TV) fl Soljr V (S □ cr) = Soljr V (S □ cr). The remaining conditions of 
the theorem are also trivial by initial hypothesis. 

Failure Rules 

Finally, we suppose any arbitrary failure rule such that S n a H- x /azZ and we 
prove that Sol^v{S □ cr) = 0. First, we note that any failure rule must have the 
following syntactic form: Si, S2 □ cr Yr x fail with conditions such that Solfv(Si) 
= 0. For example, consider the failure rule associated to Table 4: 77 < ii', £ □ cr 
lh x fail with 77, 77' G Z and u > z u' . Clearly, Sol^iu < u') = 0. In this situation, 
Soljr V (Sl, S 2 □ cr) = Soljr V (Sl) n Soljr V (S 2 □ <t) = H Sol^ v (S 2 □ cr) = 0. ♦ 



